Developer Strangelove or How I Learned to Stop Worrying and Love the Waterfall Model

Everyone loves to hate the Waterfall Model (WM) and extoll the virtues of modern development methodologies. But while people are rolling their eyes at the mere mention of the WM, they forget that it was one of the first attempts at a systematic approach to complex system development. Few first attempts turn out to be the best, but all first attempts teach us something. As such, the WM contains pearls of wisdom that should not be ignored.

Figure 1: The Venerable Waterfall Model

For the uninitiated, the WM starts with requirements. Requirements describe what the system or software will accomplish in structured natural language. An overly simple example might be: “If signal A is true, the system shall light the green LED.” A complex system could have tens or even hundreds of thousands of requirements. A modern aircraft has millions. The next step is architecture and design. Here the requirements are analyzed and categorized to guide the system or software architecture design. The result is your typical flowchart-like diagram with boxes representing functionality and connectors for interfaces. Implementation is next. The developers implement the hardware and/or software needed to fulfill requirements within the boundaries provided by the architecture. Finally, you test the implementation. Easy peasy.

There are three benefits to the WM: 1) a systematic approach 2) that is easy to understand and 3) recognizes that details increase over time. First, having a systematic approach to anything is a good idea. For system and software design, a systematic approach guides developers along a logical path of development, provides oversight for project progress, and improves reproducibility. Second, the WM is very easy to understand. This benefit should not be scoffed at; simplicity is its own reward. Third, the WM is a top-down approach that starts at a high-level of understanding and specification and works its way down, increasing details at each level, until the final product is realized and verified. This might seem obvious now but that is only because the WM engrained it in the minds of developers over the last 50+ years.

Over the years the WM has been the victim of oversimplifications and misunderstandings. For instance, one misunderstanding is that the next phase could only start after the previous phase finished. The WM in no way suggests this, in fact pictures of the WM always show the phases overlapping. That’s not to say there aren’t legitimate problems with the WM. Although it rarely happened in practice, a major downfall of the WM is that testing is shown to happen only at the end. This implies you’ve gone through months or even years of work before you run the first test. No one really did this, but it’s how the model was presented. Another problem is that the WM doesn’t contain any notion of feedback loops. It’s commonly accepted these days that refinement is done after feedback from subsequent phases and that changes from outside forces necessitate rework. But the WM is presented in a linear fashion which ignores these inevitable loops.

So now you’re asking yourself: why would a system/software engineer with 20 years’ experience in safety-critical industries put up a spirited defense of the old worn-out WM? Answer: because the Waterfall Model set the stage for the V-Model.

Tune in next time, when I describe WM’s spiritual successor, the V-Model.