Over the Waterfall

Method acting for software developers

Maybe some people are using a dysfunctional version of the Waterfall Method, as caricatured at the start of this article. But most are probably using something much closer to the Royce recommendations, as this promises to make satisfying external stakeholders in a “fixed price” project (who want to know what they’ll get and how much it will cost) straightforward.

I once had to look after a Waterfall Method for a major bank. We applied commonsense - eventually. We removed defects early, by analysing requirements, by questioning them and looking for inconsistencies and omissions, by validating data models, by unit-testing code as it was written.

The Requirements Spec and the Waterfall Lifecycle were used as guidelines, not as prescriptive mandates; and Requirements were allowed to change, under control. However, we made some attempt to feed back the financial and temporal consequences of requirements changes to those requesting them. And we didn't so much document the Method in a Method Bible, as promote it through instructor-led “good practice” training and mentoring.

There were still some issues, such as a lamentable tendency to interpret a statement like "consider doing X at this point" in what method documentation we did have, as: "you must do X, even if it makes no sense”; but with a good project manager it was a workable development method that delivered real business benefit.

These days, there are a plethora of development methods or processes, ranging from Rational/IBM's Unified Process through the OMG’s MDA to Kent Beck’s eXtreme Programming and Agile methods such as DSDM. Any one of these can be made to look stupid by “malicious compliance” to the letter rather than the spirit of the method.

And, any company that has made a mess of a Waterfall Method, developing projects Late, Over Budget and Wrong, must ask itself why it thinks it can make new methods work – whether the reason for its past development failures was the development method it adopted - or the way it adopted it.

Unless, of course, it now recognises the reasons for its past failures and addresses them – the Process Improvement which Borland, amongst others, now espouses.

I suspect that a mature, process-oriented, improvement-focused company with decent project managers will make a success of any development method, even something old-fashioned. But a company that wants to follow a mindless recipe for development success will fail - no matter how new and shiny the methods it adopts. ®

David Norfolk is the author of IT Governance, published by Thorogood. More details here.