I loved when I found this on Wikipedia on the Waterfall Process for Software Development:
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[1] though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.[2]
Yes, the canonical reference to waterfall, the thing that coined that phrase, was “don’t do this, it doesn’t work”. And yet, for 30 years this dominated the software development industry.
It's always more complicated 
It’s easy (even for me, who lived through it) to look back and think, “How foolish were the old-time software developers.” However, the waterfall methodology made more sense in the old days than it would now. That’s because the tools for designing, coding, and testing were much more cumbersome than they are now. We were coding in PL/I on single-process dumb terminals connected to a mainframe. It was inefficient on many levels, compared with today. A rule of thumb was that a mistake caught in any phase cost 10 times as much to fix as if it were caught in the previous phase. As I see it, modern agile methodologies have arisen in large part as a response to improved efficiencies all along the development process.
The Wikipedia article presents the modern pejorative connotation for the term “waterfall”, but in the old days “waterfall” was just a descriptive term. This is like the change in the connotation of “Cadillac”. When I was young, a “Cadillac” was the most luxurious, the fanciest, the most desirable (and, yes, the most expensive) car you could buy. Now, it’s just a stogy car made by a bankrupt company for fat cats.
LikeLike
It’s not so much that people were foolish, it’s that when the methodology was laid out formally in 1970 it was directly followed by “I believe in this concept, but the implementation described above is risky and invites failure.” But the methodology got baked into the management culture anyway, even though it always smelled a little funny to the engineers.
LikeLike