The Myth of the 'Waterfall' SDLC (2019)

The problem with software development methodologies is they are sold as a solution for problems that arise from organizational&#x2F;cultural dysfunctions. Up front analysis is not the problem, the problem is that the people charged with implantation are not given the big picture view and the flexibility to adapt the solution.<p>Instead of using the term waterfall as the counterpoint of agile I prefer to call it the human centipede model. In this model all of the vision, creativity, and flexibility stays with the head and the rest of the centipede just eats their shit. Developers can&#x27;t see further than the next person&#x27;s ass and have no idea why they are actually building the functional specifications that are fed to them. Implementation becomes completely disconnected from design which leads to compromised quality, missed deadlines, and products that miss the mark.<p>No task management framework is going to solve these problems.

Royce&#x27;s waterfall model is what was actually being used until the mid-2000s in most software houses. And it was one of those processes that looks good on paper, but doesn&#x27;t actually save you time or effort.<p>I don&#x27;t know where this &quot;rigid&quot; model comes from, but I never encountered it in the early days. Everyone knew you couldn&#x27;t just complete a phase in totality and then move on to the next; there had to be overlap and stepping back up to an earlier phase as you discovered new things.<p>I suspect the &quot;rigid&quot; variant is merely the hyperbole that waterfall has been reduced to since there are no more proponents of it left. Doesn&#x27;t make the Royce variant useful, though.

Nice work.<p>Agile Methodology was a self-defense coping measure for dealing with psychotic customers who cannot or will not do proper project management.<p>It was never meant as a replacement for PMI.<p>IMHO, &quot;waterfall&quot; is not having feedback loops, iteration. All of the methodologists (I read) in the 90s cautioned against &quot;throwing it over the wall&quot;, as detailed in this OC&#x27;s description of rigid sequences.<p>Plenty of today&#x27;s &quot;Agile&quot; lacks proper feedback loops. Where primary assumptions are not revisited, when new information does not lead to course corrections.<p>Maybe &quot;waterfall&quot; is just dysfunctional communication, where reasonable people aren&#x27;t talking to each other.<p>Any way. This is a great write up.

I recently took a mandatory SAFe course. The introduction consisted of mainly justifying the practice by comparing it to the waterfall method. The latter being defined absolutely ridiculos. The client is not allowed to see incremental versions until the entire thing is completely finalized, maybe 2 years later. The initial design is not allowed to be altered. Testing can&#x27;t start until the entire application is done, etc.<p>If you have to misrepresent the alternative (false dichotomy anyway) then maybe you don&#x27;t have anything of value to bring to the table. That&#x27;s what it felt to me.

The difference between what mainstream agile is and what the original authors of the agile manifesto were trying to achieve is vast.<p>This talk from one of the authors is an amazing rebuttal of what agile has become and clarification of what it is supposed to be <a href="https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?v=a-BOSpxYJ9M" rel="nofollow">https:&#x2F;&#x2F;m.youtube.com&#x2F;watch?v=a-BOSpxYJ9M</a>

I was on a project where we used Agile. The team genuinely wanted to improve itself over time and we didn&#x27;t have hard due dates. The thing was done when it was done.<p>Despite that, something felt really off. Requirements and scope kept popping out of nowhere. We tried moving onto something new yet requirements kept popping up from things we didn&#x27;t consider.<p>The project was somewhat of a legacy refactor so it was easy to say &quot;just redo X in system Y&quot; but for some reason it didn&#x27;t work out that way. I think this project could have used some the old waterfall paradigm where you did a lot of the requirements analysis up front.<p>Sure, you&#x27;re not going to capture everything, but in this case I think it would have helped everyone involved if there was more foresight put into it up front instead of continually bumping things into the night and making stories for it.

I agree with TFA that &#x27;Waterfall&#x27; is substantially a mythical creation in terms of formal definiton.<p>Nobody defined &#x27;Waterfall&#x27; as contrasted with Agile any more than &#x27;they&#x27; argued constant climate as the Climate Change folks would have it.<p>Nevertheless, I have seen, especially in a government context, the very bureaucratic rigidity that the Agile practitioners decry. SAFE wasn&#x27;t begotten in a vacuum or as a sales driver.

This talk describes how the waterfall development model was a caricature that got accidentally turned into reality: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NP9AIUT9nos" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NP9AIUT9nos</a> &quot;Lone Star Ruby Conference 2010 Real Software Engineering by Glenn Vanderburg&quot;

This is absolute gold but we need a simple and compelling story that can be told before it will inform the masses. Agile tried but seemed to miss the point of Conway&#x27;s Law that organizational structure or communication paths influence the design. Agile was trying to change or work around that fact.<p>Companies like Oracle are cargo-culting by building cloud platforms that resemble AWS but they have no appreciation that Amazon changed their internal communication practices resulting in AWS! Oracle isn&#x27;t going to do that, perhaps they can&#x27;t. Has Microsoft adapted their communication structure and is it reflected in their cloud platform?<p>What I find interesting is that cloud service adoption is allowing silos inside companies to avoid the structures that impede them--to some extent.

&gt; However, the situation was once the exact opposite. As Barry Boehm relates, On my first day on the job [in the 1950’s], my supervisor showed me a GD ERA 1103 computer, which filled a large room. He said, &#x27;Now listen. We are paying $600 an hour for this computer and $2 an hour for you, and I want you to act accordingly&#x27;<p>Adjusted for inflation, this guy was earning on the order of $40k per year.

I can remember way back around 1990 being told that waterfall was mostly a bad idea, and few shops really followed it. Rapid prototyping was agile back then. We were shown how to produce flow charts and static call diagrams in Software Engineering 201 or whatever it was called, and I felt they were doing it to show us how but also to demonstrate how much work it was, and how easy it was to get the analysis wrong.<p>As new fashions arose, instead of attacking waterfall as practiced (which, don&#x27;t get me wrong, is still labor intensive), they criticized a straw man version, because it made the new methods look even better.

In consulting they talk of a “hybrid model” which is basically iterated waterfall. Which, ftfa, is regular waterfall.<p>It works in consulting because you know the end product and schedule before agreeing to do the work (or at least you’re suppose to).<p>I use to be anti waterfall just because everyone else was but, at the end of the day, it works pretty well in its niche.

Waterfall in practice being so horribly bad for software engineering projects is kind of sad because of how low the bar is set. It&#x27;s 2021 and agile-ists still compare themselves to that dead horse.<p>I&#x27;d rather see more rigor being put in making a methodology that&#x27;s measurably better than the clusterf of short-term task tracking spreadsheets and cargo cult dogma of agile in practice today.