Pomodoro Technique® Considered Harmful (don’t worry: you are not using it)

So, you have your shining, ticketing, tomato-shaped timer on your desk and you are a proud practitioner of the Pomodoro Technique®.

I’ve got bad news and good news.

A dead stupid (yet effective) git dashboard in 3 lines of bash

 

Fork me on GitHub or just grab the code from the gist.

How To Spot The Legacy Code Writer In Your Company (Hint: It’s You)

Also available in Czech, kindly translated by Aleš Roubíček

TL;DR

Writing Legacy Code^* is a distributed activity.

^*In Working Effectively with Legacy Code Michael Feathers defines Legacy Code as “Code with no tests“, which reflects the perspective of legacy code being difficult to work with. I’ll stick to this definition.

Long version

Oh, no! Bad code again

You have been assigned a new task.

Your mission: to add a simple feature to a Corporate project. You know almost nothing about it, but the feature request sounds feasible. You can easily accomplish the task.

This is what you think. Until you open the code base.

The Definition of Definition of Done

TL;DR

Want to help editing a collaborative version of Definition Of Done checklist, driven by questions, rationales and “don’ts”?
Click here and feel free to share your ideas!

What-If Daily Scrums

I agree with Michael Kennedy when he says that Software Development could be modeled as a Knowledge Discovery Process, “the process of going from 0% knowledge about an idea to 100% knowledge of a finished product ready for delivery to a customer“.

I agree so much that I decided to adapt my future Daily Scrums to this.

In Introducing Deliberate Discovery Dan North quoted this story:

Principles and Rules

Some weeks ago I gave a talk at AgileDay.it. My talk was about a weird experimental Kanban board, and the Leitmotiv I used was around the differences between Principles and Rules. The topic was: we often learn methodologies mocking rules (often, without getting the point) rather than trying to understand the principles behind them. This bad habit sometimes leads us to take really dumb decisions.

Well, if only I had seen then what I saw today, I would have used in my talk, since I think it would have been the perfect example.

See what I found in a recent production code.
Right now, it hangs on the wall of our open space, for all the developers to see.

Preemptive commit comments

tl;dr version

Rule #1: write commit comments before coding
Rule #2: write what the software should be supposed to do, not what you did

You won’t believe how old TDD is

Kent Beck is credited as the TDD inventor.
Yet, he claims he just re-discovered it.

8 Practical Rules For Producing Decent Estimates

This the second part of How I Was Able To Be Successful Even When Forced To Use Waterfall

Rule #1: take your time

Luckily, your estimation meeting will be much more fortunate than mine (see Part I).
In my previous Scrummerfall experience, since I was forced to produce a big-planning-up-front phase, I was used to always plan 2 or 3 days for it. I was asking for an estimation when my ignorance of the problem was at the maximum level, hence I needed a lot of analysis.

Rule #1: don’t tell me the rule, state the principle behind it

Some days ago, one of my colleagues showed me an unit test, coded by someone else. It was something like

Concerto – A Board For Agile Teams

Concerto collects some ideas for a better and more effective board to be used in Agile projects.

For an unfortunate coincidence, I chose the same name of the famous Parasoft’s development management software, which I didn’t know before.
Concerto board has nothing to do with Parasoft.

Concerto – A Board For Agile Teams from Arialdo Martini on Vimeo.

A brand new, iterative and analytic Agile Methodology is born. Don’t miss it!

Disclaimer

This post is going to be pretty long.
Feel free to scroll down, or roll the paragraphs, if you think.
I’m pretty sure you will entirely read it later, since it is really interesting.

In case of panic, click here to jump to conclusions.

Introduction

Managing The Development Of Large Software Systems

I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine: years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis.

8 rules for being successful even when forced to use Waterfall (with a pretty good estimation)

Waterfall can work

No it cannot.
I mean: actually, it does, but adopting new and modern methodologies, you can dramatically improve your team productivity.
Yet, I believe most teams are using a mix of Agile and Waterfall. The reason is Waterfall is the sole methodology able to give the only information your manager needs to know: how much the project will cost and what’s the delivery date. About this, read the excellent post by Christopher Goldsbury Why Agile Adoption Fails in Some Organizations

Why you should learn some Waterfall as well

Scrummerfall

I once worked as a team leader in a startup. I was in love with XP, studying Scrum and looking forward to be able to put into practice what I was reading.

Unfortunately, my boss explicitly told me to use Waterfall. I never blamed him: before him, the company had no process at all, and was governed by anarchy; no documentation, no requirements, no clear roles. Actually, introducing a Waterfall process, he made a great revolution, and let the company succeed.

Best of #MovieLinesInCode

var it = new MP3(); sam.play(it); sam.play(it);
@chrisoldwood

$Apocalypse = now();
@johnnypixel

10 IF ALL WORK NO PLAY
20 THEN JACK = DULL BOY
30 GOTO 10
@andrewfconex

c.beginPath(); c.fillStyle="#0f0"; c.lineTo(63360*72,0); 
c.stroke();
@adomas_s

echo $bible['Eze'][25][17]; kill();
@arialdomartini

Help me, because I think Martin Fowler has a Merge Paranoia

There must be something very wrong with me: for the first time in my life I think that Martin Fowler is wrong on a specific topic. And, since Martin is Martin and I’m just a humble developer (Arialdo who?) I’m likely to be the one who’s completely off the track.Nevertheless, unfortunately, no matter how much I dig into the topic, I’m not able to convince myself that Martin Fowler’s arguments about Feature Branching, Continuous Integration and Feature Toggling are right.

Please, help me to understand what I’m missing.

Unit tests lie: that’s why I love them

When a unit test for a method implementing some feature is green, it does not mean the feature is working. The corresponding end-to-end or integration tests reveal if it’s working or if it’s broken. To Product Owner’s point of view, end-to-end tests are all that matters. Unit tests are useless.

Unit tests are meant to lie. They rely on the often wrong assumption that the rest of the world is correctly working, but only because they are explicitly mocking it: using a fake world is a deliberate lie.

To me, that’s exactly why they are so useful.

Software Developers Are Not Coders

I got shocked by Mike Gualtieri’s post about agile. I’m not expert enough to claim if he’s right or wrong. He surely gave me a lot to think, though.

The 3 most valuable qualities a candidate should have to bring value to a team

Very recently I asked Giacomo Tesio, author of Epic Framework, which developing methodology was the more successful, from his point of view.

Wrong estimation, help! I’m late! Cut features and stop waterfalling!

I won’t be able to deliver on time. My estimation was too optimistic. What can I do now?

If you can’t deliver on time, don’t. Simple, isn’t it?

I believe the best strategy is cutting features and start both constantly refining your estimation and doing Deliberate Discovery. In other words, I believe the question was somehow misplaced.