This article is more than 1 year old
Over the Waterfall
Method acting for software developers
Comment Let's throw some rocks at Waterfall development. You know, the development method which says that you have to produce about 10kg of specification document (there’s a standard, usually, for the weight of paper appropriate to different project types).
You put this on the shelf to gather dust, as some sort of protective talisman, while you use what you can remember of it to direct the enjoyable part of your job, which is cutting code.
This specification is very important, so you mustn’t change it. When you deliver something two years later that's no longer needed, because the business process went and changed on you, this is proof-positive that you were Doing It Properly and coding to spec - and therefore deserve your annual bonus. And, of course, the Waterfall says that you mustn’t test anything until just before delivery, so that any defects in the bits of your system that are still needed are disruptive and expensive by the time that you find them.
This is all very wonderful and gives you a great weapon to beat the standards police and other non-programming busybodies over the head with. Except, this terrible Waterfall Method doesn't really exist.
Even so, Tom Gilb took me to task recently because he thought that I was suggesting that Winston Royce had proposed a method like this, around 1970. Well, I'm sorry, Tom: Winston Royce really did describe a Waterfall Method in a paper presented to IEEE WESCON in 1970 (Managing the Development of Large Software Systems, Proceedings of IEEE WESCON, August 1970, 1-9). But if one reads past the first page one discovers that what he was talking about was very different to the Waterfall Method I caricatured above, the one that everybody loves to hate.
Royce’s theoretical discussion recognizes, for example, the need for a degree of iterative development and for end-user involvement (two things that successful project managers using a Waterfall model usually adopt anyway) - and the assumed absence of which form the basis of much criticism of the Waterfall.
For a good description of Royce's thesis, with annotations from an up-to-date point of view, read chapter one of Software Project Management by his son, Walker Royce (published while he was VP and General Manager at Rational Software Corporation, now part of IBM). Walker Royce says (op. cit.):
"I have always been overwhelmed by the insight presented in this paper. While most of the industry has spent considerable energy bashing the waterfall model approach, I find only minor flaws in the theory even when it is applied in the context of today's technology. The criticism should have been targeted at the practice of the approach, which incorporated various unsound and unworkable elements. I suspect that most critics never really understood this theory; they just understood the default practice."
According to Gilb, what Winston Royce actually described 36 years ago has more or less evolved into the EVO (evolutionary method) that he now espouses. But at the Unicom seminar where I met Gilb, Graham Dick of process improvement consultants Lamri, pointed out that the Waterfall Method -as commonly accepted - is still widely used - and one attendee lamented that she couldn't get rid of it, try as she might.