June 5, 2008

...Learn TDD with Codemanship

Challenging The Waterfall Delusion

It's fashionable these days for folk in the software industry to poo-poo attempts to establish standards of quality or professionalism, because - in their own words - "there's not one thing that we all agree on".

I've tried to think of something. Something that no sane, rational person could argue against.

Iterative and incremental development springs to mind. Surely there's nobody left out there who can cast doubt on the idea that it's less risky to deliver a little slice at a time, and to incorporate feedback after every increment? Surely plan-driven, Big Design Up-Front, "waterfall" software development is now so discredited that we can - once and for all - remove it permanently from the software professional's toolbox?

It's undeniably true that an iterative and incremental approach is less risky. There's a very simple statistical reason why it's better to solve complex problems in this way, which is why nature has selected it as the de facto "search engine" for finding all manner of solutions. And decades of project data provide strong evidence that the statistical argument is true.

So why can't we all now accept iterative and incremental development as the more viable approach in pretty much every situation?

The problem isn't that the argument hasn't been won. It has. Years ago.

The problem is that not everybody is prepared to be sane and rational about it. Just as some religious fundamentalists cling on to their nonsensical creation myths, in spite of the overwhelming evidence that life, the Universe and everything didn't start that way, we still have our own religious nuts who choose to ignore both the inescapable logic of the anti-BDUF argument and to ignore the mountain of evidence that supports it.

These days, we're so politically correct that we prefer to humour these poor, deluded people and make the grand mistake of allowing their ideas to persist unchallenged. And that's why waterfall stays on the table: to spare the feelings of the crazy folk who still believe in it.

In the long run, we're not doing them any favours by being inclusive to this extreme. It's much kinder to confront them bluntly with the reality: there is never a situation where it is less risky to work with less feedback less often. Indeed,l I believe that waterfall itself is a myth and that it's actually impossible to deliver anything useful without iterating - even if you leave it until the "acceptance testing" phase (or the "stabilisation" phase, or whatever you want to call that stage in the project where the user feedback starts gushing in and you're forced to make a rapid series of smaller releases, incorporating user feedback, to fix the problems and make the software for purpose.)

Posted 4 days, 17 hours ago on June 5, 2008