January 18, 2006

...Learn TDD with Codemanship

Say What You See

When you reach a certain age, years of experience teaches you to stop listening to what people say, and start paying more attention to what they do. (So, I guess I should ask why you're still reading this!)

In the UK, for the past few decades, politicians have talked endlessly, and with plausible conviction, about public sector efficiency. The trend since the days of Mrs Thatcher has been to improve efficiency, productivity and reduce costs by putting more and more public sector work into the private sector. The theory being that the private sector has its house in order and can deliver better services at lower costs.

The reality is that the tax burden keeps going up and up. While income tax remains relatively stable, more and more is taken through the back door by a miriad of stealth taxes - the scope of which continues to creep. Someone earning 50,000 GBP a year in the UK can expect - after income tax, national insurance, and all the other little duties that apply to pretty much everything you can think of (with a handful of small exceptions) - to directly benefit from less than 50% of what they earn.

Don't get me wrong. I'm a strong believer in redistribution of wealth, but I mind where the wealth gets redistributed to. The startling trend has been that, while the tax burden goes up and up, and the public sector expands and expands (and private companies skim off much of the cream - and then some - in various public-private partnerships), the quality of our public services gets worse and worse.

So I've stopped listening to politicians when they make hifalutin claims about public sector reform. I just look at the end result, and make my judgements based on that alone.

The same logic applies to software projects. I've stopped listening to developers who tell me that they're "finished", and I've stopped listening to IT managers who have "big plans" to improve the effectiveness of their departments. The proof of the pudding is in the eating.

You might think it presents a dilemma in Agile Development, since any project (agile or otherwise) will be difficult if you can't or won't trust your developers. But I'm happy to place trust in developers to make their own decisions. Making decisions and reporting progress or making promises are not the same thing. I trust developers when they say "the best way to do X is using Y", but I choose to only beleive the evidence of my own eyes when they say "it's finished". It either is finished or it isn't. If it is, then they can give me a working version of it and I can see for myself.

Whether or not they actually are finished is not for them to say. The customer decides if they're finished, because the customer has the final say on whether a feature has been successfully delivered or not. Harking back to my trusty golf analogy, the customer decides if the ball is in the hole. The same principle applies when you get your hair cut. It shouldn't be up to the barber to decide that you're happy with his handiwork. He grabs a mirror, shows you what he's done, and asks "is that okay?" Only if you say "yes" is he definitely finished.

Tragically, on many projects it works the other way around. The developers decide when they're finished, but are not allowed to make important decisions about how the software is developed. This is the worst of both worlds: you have progress assessed by people who don't really know what's required, and method decided by people who don't know how to build software.

That's just plain wierd in my book... (Almost as wierd as putting lawyers in charge of public services)

Posted 1 week ago on January 18, 2006