Flawed waterfall software
In an attempt to prove that I can turn any weekend away into a software development blog, I couldn’t pass up the chance to mention that these last few days I have been lucky enough to take a road trip from Washington DC to Niagara falls. No prizes then for guessing that I am trying to ‘crowbar in’ a reference to the waterfall model of software development into my usual diatribes.
The genesis of the term ‘waterfall’ when used to describe software development is frequently attributed to a piece of written work in 1970 by one Winston W Royce. Although Royce omitted to use the actual term himself, he did describe a sequential ‘waterfall-like’ software development methodology and made it clear that it was an essentially flawed concept. The model’s inherently inflexible and non-iterative form make it worthy of note, but unpopular for most modern software engineering application development environments.
Using a little artistic license if I may. A similar set of flawed software references can be seen when looking out over Lake Erie as it rushes headlong into a series of spectacular drops:
1 – not all software projects are the same: the straightforward American falls looks remarkably regular in comparison to the wild bend of the famous horseshoe falls – describing software projects as waterfall processes looks like a dangerous assumption so far…
2 – the first result is chaos – as the water crashes down you can’t see a thing, it’s all spray, noise and confusion until the river flattens and then takes a straight course which just won’t change… hmm, I didn’t really want my software project to go off in that direction… too late now, sorry!
3 – human circumvention and bridging – there’s always the option for human factors to bridge or sidestep the flow of the falls and there are several road bridges in just such places at Niagara, so humans may decide that they don’t want to go with the flow after all…
4 – energy can be drained off to slow the project down – actually, the hydro dams at Niagara do just that, if we want to put the breaks on the project instead of letting it flow naturally we can do that…
5 – there’s always a risk taker out there – even if you think your project is being sensibly managed, there’s always some fool willing to throw themselves over the edge in a barrel isn’t there?