The irony is that the proposition that "someone wrote a book that proposed waterfall as the best software method" is itself a strawman argument.
To my knowledge, that has never been claimed.
Waterfall is what many of us old fogies in the industry experienced as the "defacto" methodology for a long time. It made intuitive sense that in order to design a build a project that you would first, you know, DESIGN it. Then you'd kick over that design to software developers that were expected to implement it.
Iteration in the design and development process, the idea of "people before process" and getting designers and engineers to collaborate early on etc. was not obvious. That's where all of Agile's "waterfall" talk came from. The fact that for a long time what companies were doing, while never exactly the same process as each other, was always waterfall-like because that's what made the most sense in an industry that was very new and in which no one knew wtf they were doing... so they took knowledge from other domains and tried to make it fit. That's a large part of what Fred Brook's The Mythical Man Month talks about.
It's only now that a new generation of developers has come up in a world where all they've ever known was "Agile" and "Scrum", that the world they know is so far removed from the "non-Agile" world that these books describe.
A colleague of mine the other day was talking about experimenting with something using the browser's `postMessage` API 8 years ago. My initial reaction was "did postMessage exist 8 years ago?" And then I remembered that 8 years ago was 2016 and it's already 2024. Many "experienced" people coding today have 5 years experience... and then they talk about concepts that were a reaction to how things were being done in the 80s and 90s as if those decades never happened ... because if they had even been born yet they were still children, so they weren't there to live that reality and the pain that what came later was a reaction to.
Which, given that that's a military spec, also speaks to a motivation for such a tightly controlled approach: the cost of design changes is truly immense. When you have a large government project with MANY different contractors working on different pieces of the system, a lot of Agile principles need to go out the window. The spec needs to be fairly well nailed down up front because a late change that affects adjacent systems gets really expensive when those adjacent systems are being managed by a completely different company. That requirements tweak may now be a full on contract renegotiation. And, as Boeing's recent woes illustrate, communication among all the subcontractors may be so poor that even identifying the potential impact of a specification change may be difficult to do reliably.
Not such a big deal in a lot of tech projects where it's relatively inexpensive to solve problems as you find them. But Mars rovers don't get to have canary deployments.
Also, even then, it's still not really "textbook" waterfall.
"Waterfall" is just a pejorative term used against the kind of project management that uses a Gantt chart, which kinda looks like a waterfall. This kind of project planning is necessary when you've got engineering steps that are time sensitive and take months to years. Like if you're building a large bridge you need to schedule the resources to do individual steps a long time in advance.
Writing software was initially run like this and there was a big pushback because most of those old school engineering methodologies just aren't justified because when you're writing software all of the steps look pretty similar and the design/build/test cycle can go through a full cycle in minutes instead of years and you get to do it millions of times instead of, like for a bridge, only once.
Those engineering practices are still necessary when you're building things, sometimes a bit less so with electronics hardware these days we have prototyping that can turn around very quickly, but still if you're doing a large physical engineering project, you do lots of "waterfall" because that's the best tool for the job because the job requires it.
> designers and engineers to collaborate early on etc.
The really scary thing to me is that I'm old enough to remember when all the trade rags were excitedly talking about how it's a great idea to not just "throw your design over the wall" but work with the software guys to understand what their needs were and accommodate them.
The scarier thing is that they were talking about this in the year 2000.
To my knowledge, that has never been claimed.
Waterfall is what many of us old fogies in the industry experienced as the "defacto" methodology for a long time. It made intuitive sense that in order to design a build a project that you would first, you know, DESIGN it. Then you'd kick over that design to software developers that were expected to implement it.
Iteration in the design and development process, the idea of "people before process" and getting designers and engineers to collaborate early on etc. was not obvious. That's where all of Agile's "waterfall" talk came from. The fact that for a long time what companies were doing, while never exactly the same process as each other, was always waterfall-like because that's what made the most sense in an industry that was very new and in which no one knew wtf they were doing... so they took knowledge from other domains and tried to make it fit. That's a large part of what Fred Brook's The Mythical Man Month talks about.
It's only now that a new generation of developers has come up in a world where all they've ever known was "Agile" and "Scrum", that the world they know is so far removed from the "non-Agile" world that these books describe.
A colleague of mine the other day was talking about experimenting with something using the browser's `postMessage` API 8 years ago. My initial reaction was "did postMessage exist 8 years ago?" And then I remembered that 8 years ago was 2016 and it's already 2024. Many "experienced" people coding today have 5 years experience... and then they talk about concepts that were a reaction to how things were being done in the 80s and 90s as if those decades never happened ... because if they had even been born yet they were still children, so they weren't there to live that reality and the pain that what came later was a reaction to.