February 28, 2009

...Learn TDD with Codemanship

Burn The Perfectionist!

As soon as I get a chance this weekend, I'll be doing a write-up on Thursday's Software Craftsmanship 2009 conference. But I just wanted to share a thought before then about the debate that's been bubbling away on various blogs, discussion groups, lonely hearts classifieds and electric parsnips about this craftsmanship metaphor.

To me, at least, it's not a metaphor. A craftsman is someone who applies skill and care to the creation of a high quality end product. It is in no way metaphorical or analogous to call someone who applies skill and care to the creation of high quality software or systems a "craftsman". But that's just my opinion, and if we temporarily put aside the fact that I'm always right then there are some interesting philosophical discussions that you can have on that. None of which will probably help in any practical way to move our profession forward.

But such debates and navel-gazing can be very entertaining and it keeps the more introspective of minds occupied, lest they fall prey to darker thoughts and whimsies, I s'pose.

The other thing I've noticed is how some people view this whole craftsmanship phenomenon as a form of elitism or extremism. And they're quite right, of course. Anyone who expects software developers to take pride in their work and to only ship code they feel they can be proud of is obviously a babbling lunatic or some kind of super-advanced alien lifeform from the planet YAGNI.

To suggest that software should be as good as we are capable of making it, and that we should constantly strive to raise that bar, or that we shouldn't ship code until we are happy with its quality, is heresy of the worst kind, and anyone who dares even to whisper such blasphemies in the presence of the High Priests of Pragmatism must be burned at the stake so we can prevent these very dangerous ideas from spreading (especially to the Visual Basic community, who can be highly impressionable, as you know).

These words - "pragmatism", "perfectionist", "extreme", "dogmatic" - they have strong emotional connotations in business. No matter how reasonable and well-supported a person's point of view is, accuse them of being "dogmatic" or a "perfectonist" and customers and managers will react instinctively to neutralise the perceived threat in their midst. They won't pause and weigh up the arguments and the evidence. They'll just make an instant knee-jerk decision because, in business, words like that usually trigger deeply-rooted primal reflexes. "Burn the perfectionist!" they'll scream and you'll soon find yourself being carried down to the Job Centre on the shoulders of an angry mob of pragmatists.

I'm discovering that there's little point in engaging in debate with these people who cite "pragmatism" as a justification for lowering our already-way-way-too-low standards of professionalism and quality. 20 years of industry studies on the relationship between quality and productivity have shown beyond any reasonable doubt that it's a bogus conflict.

There are, of course, very expensive and time-consuming ways of achieving high quality software. Testing your software after it's been delivered, for example, is a very expensive way of catching requirements misunderstandings. In fact, it's about 100-1000 times as expensive as testing your understanding of each requirement before you implement a solution for it.

Anyone who has failed an exam because they misunderstood the question will tell you that taking time to read the questions carefully is actually very practical advice. That's real pragmatism. You do it because it works, and not just because you're afraid to say "no" to some customer or pointy-faced boss or because you don't have time to learn a better way.

And it does work. Defect prevention works. Period. There's really no reasonable doubt about that.

Ironically, the reason why "pragmatists" don't have time for niceties like adequate test automation or enough refactoring is because they are too busy dealing with the far more costly consequences of not doing these things in the first place. So they're stuck in a vicious downward spiral where release after release the crippling burden of crappy code and costly manual regression testing sucks them ever deeper into the abyss. The only way they can get back to the surface to draw breath is to start making much bigger payments against their technical debt, if they're to have any hope of getting it down to a manageable level where they can start delivering value to their customers again.

Anyway, that's my Saturday rant. I'm off to Planet YAGNI via the medium of pure thought to waste 10 billion man-hours attempting to perfect a single line of code with all my colleagues from Mount Olympus.




Posted 9 years, 5 months ago on February 28, 2009