I was listening to episode #40 of my favourite podcast Happy Path Programming by Bruce Eckel and James Ward. The episode features agile coach Barry Hawkins who talks about flaws and misconceptions when interpreting agile methodologies. Among other things, he shares some interesting facts about the dreaded Waterfall model. Turns out that the usual perception of Waterfall being rigid and dated is nothing but a massive misinterpretation of what it actually means.
I want to keep this post short and to the point. Let me delve right into it.
Table of Contents
“Waterfall” Never Existed
At least not in the sense as it is commonly referred to these days. Wikipedia defines the Waterfall Model as rigid, or less iterative and less flexible if that sounds better to you. However, it also correctly points out that a feedback loop was indeed part of the original article published by Winston W. Royce in 1970.
In his article Managing the Development of Large Software Systems, Royce reflects on almost a decade worth of experience with designing software. You can download the original paper from various sources. Here is the one I found on GitHub. It’s a short paper comprising only 11 pages of text and diagrams.
First observation to make is that Royce never mentions the word waterfall. It was coined in later on and the point of reference here is the second diagram in Royce’s article whose shape indeed resembles a waterfall.
Without any other context this diagram describes nothing but a totally rigid and impractical view on delivering a complex program. Everything flows from left to right and the further down the more expensive it is to deal with changes. There is no feedback loop whatsoever, hence whatever was decided in the beginning (probably months ago) better still holds true when the coding phase is over and we are about to test the final product.
This is however not how Royce envisioned the delivery should be executed!
Adding a Feedback Loop
I believe in this concept, but the implementation described above is risky and invites failure.
Winston W. Royce
In a quick succession, literally on the next page, Royce comes up with other two diagrams. The latter one nicely depicts a principle of timely and iterative feedback loop. Zoom into the final diagram you can find on Wikipedia and this is what you get.
Now it makes much more sense, doesn’t it? Just like before, you gather the requirements, analyse the problem in depth, prepare designs, code it up (possibly a prototype) and test the crap out of it. However, if things don’t work out as planned you go back to the design phase and reiterate on the requirements, initiate a new round of analysis etc. Rinse and repeat as many times as necessary. Agility embodied.
Do it Twice!
Throughout his brief article Royce provides useful insights beyond just the delivery execution. He talks about the importance of testing the waters with a pilot version. Once tested in real-life scenarios on a small group of users (with possibly many corrections and redeployments), only then should the program be fully rolled out to production.
Royce makes quite a few inspiring points that stood the test of time. For example:
- Good documentation helps break dependency on individuals.
- Second pair of eyes provides unbiased verification and helps mitigate bugs and misunderstandings.
- Test coverage matters, aka test every logical path.
Summary
In this brief post I wanted to address one of the most common misconceptions around agile. As many other developers I too experienced a negative impact on productivity and personal happiness whenever a flawed or fake version an agile methodology was put in place. Therefore, I can appreciate honest and expert advice on the subject.
I highly recommend listening to the episode featuring Barry Hawkins where he unpacks on many flawed perspectives, micromanagement and misuse of agile in general. It made me realise that software engineering is not the only fast paced industry and many of the borrowed concepts had been here for a long time for legit reasons.
