The Waterfall Model

David A. Wheeler

2018-04-28 (first 2018-04-13)

The “Waterfall model” for software development is a relatively linear sequential approach for developing software. The idea is that progress flows in largely one direction ("downwards" like a waterfall) through individual phases from conception through later steps (such as analysis, design, and construction). There may be some feedback, but the waterfall model assumes that feedback from any one step is limited and mostly back to only the previous step.

The waterfall model traces back primarily to Winston Royce’s 1970 paper, "Managing the Development of Large Software Systems". Royce didn’t call it the “waterfall” – he called it the “simpler method”. But what Royce described early in his paper is clearly the waterfall model - work progresses in a single sequence of steps, possibly with some iteration between adjacent steps.

However, many people did not read Royce's paper, even if they cited it. Royce describes the simple (waterfall) approach, but then explains that the waterfall model is “risky and invites failure” and that “in my experience, the simpler method has never worked on large software development efforts”. Indeed, he emphasizes that various changes to the waterfall model must be applied, such as using iteration, to have a reasonable chance of success in a larger project. The bottom line is that Royce recommended against using the simple waterfall model, even though later authors referred to his paper when arguing for using it.

I should add that in my own experience, Royce is right saying that the waterfall model is a risky approach to software development. In the vast majority of cases I strongly recommend against a waterfall. A waterfall model can work well in small projects where everything is completely known ahead-of-time and the requirements never change, but such projects are rare. The waterfall model looks simpler and more rigorous on paper, and those are two reasons why people keep trying to use it. But many people have failed when they try to apply it, or at least found it to be especially costly. In practice, some sort of incremental or iterative approach is usually much less risky.

Unfortunately, many people just looked at the easiest-to-read pretty figures in the paper, and didn't notice the text that explained why the waterfall model was risky. The text and some of the key figures are right next to each other, on the same page! But people still ignored the warnings. Since many people just looked at the earlier figures, and skipped the more complicated later figures, they totally misunderstood Royce's paper. This is discussed further in “Don't draw diagrams of wrong practices – or: Why people still believe in the Waterfall model” by Tarmo Toikkanen (2005-09-09).

Once the pictures became widespread, they became fossilized in various organizations and standards. For example, the US Department of Defense (DoD) developed the standards DOD-STD-2167 (4 June 1985), later revised to DOD-STD-2167A (29 Feb 1988), aka "Defense System[s] Software Development". Technically you could iterate in 2167A, but a variety of factors made that difficult in practice. Those standards are officially no longer required, but the practices remain. The Final Report of the Defense Science Board (DSB) Task Force on the"Design and Acquisition of Software for Defense Systems" (February 14, 2018) explains that the DoD "still largely buys and develops software developed using the slower traditional Waterfall approach that was mostly abandoned by commercial companies years ago." Once something becomes entrenched, it is hard to change.

There are several lessons to be learned here:

Do not mindlessly follow fads. The computing field is way too interested in what's the latest trend. For any given approach, there are pros and cons - be sure you weigh them. The waterfall is intended for situations where the requirements can be completely known and never change; that is not a common situation in software.
Look at the sources and the evidence. People repeatedly cited a document that refuted their claims. With the web there's even less excuse to not check claims. Even if there's a claim, what is the evidence behind it? It's best to check that out. In this case, the most-cited supports refuted the claims.
Newer is not better. Older is not better. Better is better. Just because something is old does not mean it is bad (or good). Just because something is new does not mean it is good (or bad). Evaluate each proposal on its own merits, and for your specific circumstances.
It's all about trade-offs. Developing software is engineering (applying knowledge to build a useful product or service). Engineering is all about evaluating trade-offs to make good selections for the circumstance.
Beware of drawing diagrams of wrong practices. A picture is worth a thousand words. But are they the right thousand words? People will often believe the picture and ignore the words.
Beware of figures. Since some people will draw diagrams of wrong practices, be vigilant when reading figures; they can mislead. A story is probably helpful here. The American cargo ship SS El Faro sank on October 1, 2015 in the Atlantic Ocean, leading to the death of everyone on it, because it unintentionally headed into a category 3 hurricane. The National Transportation Safety Board (NTSB)'s report on the El Faro determined that a key cause was that the captain used "noncurrent weather information". The El Faro was "receiving sufficient weather information for the captain’s decision-making regarding the vessel’s route", but it was not used. One system (BVS) plotted information in a way that was visually appealing, while another system (Sat-C) delivered the information only as text coordinates (which they then had to manually plot). However, the BVS data was much older, so when the hurricane changed course, instead of avoiding danger the ship went straight into it.

In short, beware of using the waterfall model, and try to learn from past fads to protect yourself from the current fads.

Feel free to see my home page at https://dwheeler.com. You may also want to look at my paper Why OSS/FS? Look at the Numbers! and my book on how to develop secure programs.