February 12, 2011

...Learn TDD with Codemanship

Customers: Demand Certainty About What IS, Not What Might Be

One of the more frustrating things about growing older is that I grow increasingly impatient of irrational, unreasonable managers and customers.

One of the ways in which customers especially piss me off is when they demand accurate predictions of what will be delivered, when it will be delivered and how much it will cost - something no mortal is acapable of giving them on even quite simple projects - but who then have to be dragged kicking and screaming to see what you actually did deliver.

To me, this is arse-backwards thinking: demand certainties when none are possible, then run away and hide from certainties when they're staring you in the face.

Predictability in software development is a red herring. A fool's errand. A white elephant. The only outcome anyone can honestly guarantee up-front is failure. If you want absolute, 100% certainty, then I can take steps to absolutely 100% guarantee nothing will get delivered. Everything else is a maybe.

Thanks to the magic of executable specifications, though, I can, at any specific point during development, absolutely 100% guarantee that we have delivered what we say we have delivered. We can compile it, test it, gift-wrap it and send it right to your desk and you can see it with your very own mince pies for what it is.

Software development's a big gamble. Before we've rolled the dice, we can't know anything for sure, other than the fact that we can't know anything for sure. You place your bet, you roll the dice, and maybe you win, maybe you lose. But once the dice are rolled, only then can you have certainty.

So why do so many clients turn away from the table, stick they're fingers in their ears and go "la la la, I'm not listening" when it's a matter of a casual glance to look at the numbers on the dice? You've rolled the dice. Look, you can see how they landed. You can see if you won. You can see how much money you can afford to bet on the next throw.

You are in a position to be well-informed. To be "in the know". To have facts to act on.

Agile teams (with their trendy t-shirts and their cool and hip seven days of beard growth and their Rage Against The Machine iTunes downloads) should be in a position to show the customer exactly what they got for their money on a frequent basis. Weekly, maybe fortnightly. Maybe every time a feature request gets turned into a working feature.

A rational, reasonable client should much rather settle for these powerful certainties than pin all their hopes on the divinations of project managers before the work's even begun.

Knowing what is usually leads to better decisions than knowing what might be, especially in our line of work where "what might be" can often be an entire universe of potential outcomes.

Most customers, of course, are not really customers at all. They're custodians of other people's money - middle men at best. Failure to keep a close eye on the emerging reality as your project unfolds is a deriliction of your duty, as is failure to act on that picture when action needs to be taken.

In Hollywood, where people have names like "McG" and take medical advice from former Playboy centrefolds, they still manage to be rational enough to demand to see rushes of a movie pretty much every day to see how their money's being spent. Look and learn, customers. Look and learn.

Posted 10 years, 1 month ago on February 12, 2011