April 23, 2007

...Learn TDD with Codemanship

"Good Enough" Really Means "Almost Perfect"

There's been an insipid propaganda, put about by people who should know better, that you can take quality too far. They do it to curry the favour of their seniors, of course. In most businesses - even businesses who blow the quality trumpet in public - daring to utter the "p" word (perfection) is a hanging offence. You don't win friends on the board by striving for the ultimate in excellence. A very popular phrase among brown-nosers these days is "perfection is the enemy of good enough".

Indeed, "good enough" sounds much cheaper, doesn't it? And besides, you can never actually achieve perfection, can you?

Striving for perfection is a great way to ensure you always get passed over for promotion. You might as well go around telling everybody that the Royal Family are, in fact, extraterrestrial lizards. Anybody who uses the "p" word is surely a nutter, yes?

Luckily, I'm here to put the record straight:

Yes, you can take quality too far. And, yes, perfection is unattainable in the real world.

BUT, the vast majority of development teams are in no danger of ever taking quality too far and come nowhere near to achieving perfection. AND, countless studies have shown that almost perfect software is entirely achievable. Indeed, not only is it entirely achievable, but it's actually cheaper and quicker to deliver almost perfect software than the crap we're all churning out today. The line in the sand we call "good enough" is not where we think it is. In reality, "good enough" and "perfect" are so close to together, and we are so far away from either of them, that they might as well be the same line. We should be striving for perfection because "good enough" is, in almost all cases, almost perfect.

Let me tell you something about the crap we're churning out today: first of all, we're spending more of our time fixing bugs we could have avoided when we could be adding value to the software with new and updated features. Secondly, it's riddled with duplication, inter-module dependencies and the usual code smells that build up as we work, which slow us down even more.

Teams that do test-driven development will tell you that they have to deal with an order of magnitude less bugs. And teams who regularly refactor the code to maintain the design quality will tell you that they can maintain their productivity for longer, too.

But, guess what? Even teams who do TDD and refactoring and pair programming and all that other good stuff that helps keep your code in shape for longer - it's still nowhere near enough to be "taking quality too far". You can pull the quality lever much, much harder than that and still be delivering better code, faster and for less expense. You have to pull it really, really, really hard before the cost of pulling outweighs the benefits.

It is true that a few - and I mean, literally a handful - of organisations developing safety-critical systems have spent so much time and effort on quality assurance that the cost of a line of code went up. But these are isolated cases. In 99.9999% of cases, improving quality saves time and money - even on quite short projects. You are almost certainly on one of those projects. So if you've been smugly sitting back reading this and thinking "He's not talking about us. We're one of the 0.0001%" - yes, I most very probably am talking about you. And me. And pretty much every software developer I've ever come across in the last 15 years. None of us - not one single solitary one - has gone as far as reaching that line in the sand labeled "good enough".

So when a manager or some other greasy-pole-climber spreads the FUD that you're in imminent danger of putting too much time and effort into quality, just remember that they are almost certainly wrong. Stick to your guns and keep pulling that quality lever until it hurts, and then pull it harder.
Posted 14 years, 4 months ago on April 23, 2007