Software Development

Monsters, Names, Pot-Roast & The Waterfall Model

11 Comments
“Antony” (without the ‘H’) is the anglicised version of Antonius. In victorian times (there or thereabouts I’m guessing), among those wishing to appear oh so intelligent, gossip spread that the spelling of “Antony” was wrong… For, so they would say, it is born of the greek word “anthos” (meaning “flower”) – oh dear… so many poor children with misspelt names… 

Despite being completely wrong, the world forgot of my name’s etruscan origin and spelt it with an ‘H’… This misinformation established itself through the eras so much so that, today, the de-facto spelling is “Anthony”. It has even found it’s way into the American pronunciation of the name as: “An-thon-ee”.

Waterfall development has something in common with this story… somehow, through misinformation, what it once was has been warped, into something else.

The key difference is that Waterfall is now increasingly represented as was originally intended. Unfortunately for me, my name is not…

 

Monsters & Legends

Some might think that the Waterfall Model is an approach to software development, first explained (but not named) in Winston Royce’s 1970 Paper “Managing the Development of Large Software Systems” (PDF), but they could be wrong…

Somehow, it seems to have become something else… it became the way (many) people thought software should be developed… the norm for software ‘professionals’. Years of anecdotal failure followed and Waterfall became a legend – told time and again much like a scary camp-fire story… The enemy of effective software development… A monster that will consume all the resources it can, spewing out nothing but documentation, rarely concluding in working software – at best 20% of the time.

This negative view, to what was once the de-facto approach to software development, is actually far closer to Royce’s original words on Waterfall than many seem to know…

 

The Truth & Technology

In Royce’s original paper, he shows a progression of activities, that came to be known as the waterfall model.

What we rarely hear of is Royce’s original words on the subject:

“…the implementation described above is risky and invites failure.”

Further to this, Royce goes on to explain that the reason that this cannot work is because there are too many things we cannot analyse up-front:

“The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable. They are not the solutions to the standard partial differential equations of mathematical physics for instance.”

He explains that we need feedback loops. He goes on to warn of (a conservative) 100% overrun in schedule and costs:

“…invariably a major redesign is required. A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs.”

Some of Royce’s strategies, like “Involve the customer” and obtaining early feedback, have lived on in modern (Agile) methodologies. Beyond that, we should remember that his specific recommendations on how to solve the problems of a waterfall model were all based on the technology of the time.

 

Pot-Roast & The Cost of Change

In 1970, computing was much more expensive than it is today. In those days, changing software was far more expensive than changing pictures and words on paper. It was also much harder to express your design in a human-friendly way in the programming languages of that time. As a result of these and other factors, documentation was a major part of how Royce tried to solve the inherent problems of the Waterfall model.

 

Technology, tools & thinking have moved on and our documentation no longer needs to be static. It lives. It can breath. The specification can automatically verify that the implementation does what we said it should do (e.g. as in BDD Specs or ATDD/TDD Tests). Modern programming languages allow us to express the design and our understanding of the domain far more clearly, negating the need to first detail our thoughts on paper in natural language. We simply don’t have to cut the ends off that pot-roast anymore.

 

Only now, at the end…

Waterfall, thanks to the popularity of Agile, has gone from something I was shown at school as “how software is developed” to being seen in the light that it was originally presented – how software should not be implemented.

This is despite those who still profess the legitimacy of Waterfall and those still shocked and surprised when they hear of Royce’s own words against the monster he unintentionally created.

As for my name, I hold out little hope for change. I doubt that the world will use my name as it was originally intended and so I have resigned myself to needing two domain names… one with an ‘H’ in it, and the correct one without – I wonder which one brought you here.

  • Was he not simply putting a name to a pattern that people were already practicing? I say this because in my experiencing people “doing” Waterfall are rarely doing it explicitly but are more likely doing Prince2 or a bureaucratic and formal process which reflects their organisational structure. When they do recognise the name it is more like a moniker and I very much doubt showing them Winston Royce's original paper and comments will either come as much of a revelation or likely to change their opinion

  • Matt Heusser

    “Only now at the end, do you understand” – any post with an Emperor Palpatine quote in it must be good. And the other stuff was good too!

  • I think it's more subtle than that. The reality is that nobody who delivers anything useful is really doing waterfall. They have to iterate towards a workable solution just like the rest of us. To hit the nail on the head first time is as unlikely as a golfer hitting a hole in one. What tends to happen is that they try to get it right first time, and then end up with a whole bunch of change requests (often masquerading as bug reports) which they have to tackle in very short feedback cycles during what's commonly referred to as a “stabilisation phase”. On these projects, this is where most of the actual lessons are larned and value is added.

  • Thanks for the comment Rob.

    Maybe he was talking about the way people did things at the time. He had some great points, either way. Regardless, there are those that argue in favour of a waterfall approach (either explicitly or indirectly). I meet them occasionally.

    Sometimes I meet people who put forward arguments against iterative approaches. I can also use some of the arguments in my blog post in these situations too.

    I agree that if someone is in favour of a Waterfall approach and uses the name explicitly, just showing them Royce's article probably won't change their opinion. Showing them my article might 😉

    People I meet who do talk in favour of a waterfall approach (as a moniker or otherwise) do tend to find it a revelation when I share Royce's words with them since few of those I've met have ever read the article.

    Thanks again for your comment.

  • Here-here!

  • The more interesting part of the Royce paper is the conclusion in the end:
    “Figure 10 summarizes the five steps that I feel necessary to transform a risky development process into one that will provide the desired product. I would emphasize that each item costs some additional sum of money. If the relatively simpler process without the five complexities described here would work successfully, then of course the additional money is not well spent. Ii, my experience, however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed.”

    Now, the question is, whether Agile is a way to overcome the five-step process and outperform the costs I need to invest into the methodology. Maybe it's time for science to re-visit this statements after 40 years.

  • Pingback: July 15, 2010: An Apple Comment A Day « Rails Test Prescriptions Blog()

  • Pingback: Why the waterfall methodology illustrates how software should not be implemented | Brian Heys - software testing consultant/contractor()

  • I'll back again for sure, thanks for great article 😀

  • I’m so love this blog, already bookmarked it! Thanks.

  • Jerrel

    waterfall brought me here.. nice post