Waterfall Method

A description needs to go at WaterFall, or maybe WaterfallModel, but until then we'll create another page so that for those who are too lazy to search the 19493 page WikiList can have yet another place to talk about this. But if you don't know what waterfall is, and you don't feel like clicking on the other links, it looks something like:

Page name notwithstanding, "waterfall" is a model of software development, but definitely not a method, the difference being that the model does not tell you how to do anything. Maybe if we begin to get this straight, a lot of confusion and bad feeling about the natural wonders of falling water will ... how you say ... evaporate.

By the way, if you notice the little phrase "Unit testing" under Implementation, that's what most people think of unit testing in the Mystical Land of Software Engineering. On UnitTestsReconsidered, there was a mismatch between the XpVsStandardDefinitionOfUnitTest.

The diagram above doesn't show the traditional waterfall model, which was one way, and which is the reason for its bad reputation. As drawn the above diagram could be followed in a iterative and/or rapid prototyping process, switching among various development activities as necessary, and that wouldn't be a bad thing. Think about it: water generally does NOT fall back UP a waterfall. And traditional waterfall projects rarely admit that they messed up a previous stage and need to revisit it (because of mental inertia ("We finished design; no, you can't update it!"), or the schedule is rigid and has no room for change ("We have to deliver in 90 days; we don't have time to redesign..." [even if we'll overshoot by 120 days when the flaws come out in acceptance testing]), etc...

The first published diagram of the waterfall that I know of was in WinstonRoyce?'s paper, and the term "waterfall" isn't even used in that paper. It may have been drawn on many napkins prior to that, and undoubtedly has an oral history that predates its written history. But in the interest of not rewriting history, could we have your sources for the notions of "traditional waterfall" above, please?

These are discussed in considerable detail in SteveMcConnell, 1996. RapidDevelopment: Taming Wild Software Schedules, MicrosoftPress.

Commercial software projects often reduce the formality of the full waterfall model. In the last few years, a paradigm known as ExtremeProgramming has emerged that emphasizes reducing the cost of software changes, developing test cases before coding, developing code using pairs of programmers, and putting most of the documentation into the code [KentBeck, 2000: ExtremeProgrammingExplainedEmbraceChange, AddisonWesley]


Royce's paper was published in 1970, while the McConnell and Beck sources above are 1996 and 2000, respectively. On the SteveMcConnell page of this wiki, McConnell is credited with having "introduced" the spiral model. There is no mention there of BarryBoehm's paper, "A Spiral Model of Software Development and Enhancement" [1987], in which Boehm discusses an early (1957) "stagewise model", and subsequent enhancement to it by Royce (in the 1970 paper) including feedback loops and prototyping, which Boehm calls the "waterfall model". Boehm says this about Royce's waterfall model:

He then goes on to discuss evolutionary development models and how they ease the problems of the more rigid waterfall, but introduce some new [old] difficulties:

In introducing the spiral model, Boehm characterizes it as "based on experience with various refinements of the waterfall model as applied to large government software projects. The spiral model includes most previous models as special cases..."

The difference between Boehm's treatment of waterfall and early stagewise models and the way this wiki treats them is a matter of maturity. Boehm's analysis is historic, incremental and evolutionary. Most importantly, he maintains the value of waterfall notions in their place among a matrix of refinements and improvements. The treatment of waterfall on wiki is ahistoric and non-evolutionary. Wiki hasn't done its homework with respect to software process models, and makes a poor example of evolutionary values, all its recent XP hoopla notwithstanding. Wiki grow up.

-- WaldenMathews

The way Wiki "grows up" is by refactoring. It changes, improves, by the participation of those who are expert in the field taking the time to correct errors, remove the heat and retain the light. At present this topic is treated on 5 pages by page name: WaterFall, WaterfallAnalogy, WaterfallMethod, WaterfallModel, WaterfallSyndrome, and on 90 other pages by referring to it.

The topic could do with a large refactoring by one who has the "ability to make it fully conscious". As you said in another place:

"As you develop something ... anything ..., what is it that guides you toward the correct result at any given moment? My thesis, again, is that that "thing" can be expressed, evaluated, improved, etc. But it depends on your ability to make it fully conscious, and then to express it. You may not wish to do either, but that's a different matter." -- WaldenMathews

I accept your nomination, and will now take applications for a pairing partner with whom to address the task. An openness to the value of contributions pre-1990 to the software field is a key criterion for this position. Interested applicants should contact me by email. -- wm

... but definitely not a method, the difference being that the model does not tell you how to do anything ...

It was a method at the time. Specifically, it told you "Do design, then coding, then testing, then you're done". Nowadays, the 'how' is more detailed, but back then, that was the 'how'.

What time are you referring to?

The time it was invented/discovered. Honestly, I haven't a clue as to dates. I just know that at one time, the WaterfallMethod was the NextBigThing.

Another Waterfall: http://www.worldofescher.com/gallery/internet/waterfall.html

View edit of August 21, 2009 or FindPage with title or text search