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.
Requirements are the key to success. Some customers have great requirements, and some have crummy requirements. Crummy engineers have a chance of muddling through if the requirements are good and understood. Good engineers with a good model will stumble (or grumble) with crummy requirements.
The WM allows for loops, but try convincing managers to allocate time and staff for the looping. The enlightened ones might add in a little.
An engineer with some understanding of the product (system requirements, experience, napkin, etc.) can start working on tests even before the requirements are complete. I made the mistake of saying out loud in a meeting that I was working on tests before software requirement completion, and was greeted with stares as though I had grown a third eye.
As a requirements engineer, I whole-heartedly agree! Requirements will be an interesting challenge for the EB project (see subsequent posts) since we don’t really have developers in the traditional sense. I hope all is well at Astro. I miss you and the old crew. 🙂
Just read you posts, great reads.
Working for over 15 yrs in automotive and today I (again) had to explain, that although we want to be “agile”, we need some product reqs writen down and a process to get the missing ones! Having user stories in Jira is not enough to be certain we are going to hit what our customer (actually thinks he/she) needs …
Keep at it, looking forward to new posts!
Sorry for the anonymity, I am kind of like that way :)!