I have been looking closely for years ever since someone wrote on Wikipedia that I was an "advocate" of the waterfall method. There has NEVER been an "advocate" of the method. Nobody has ever said that strict phase-by-phase progression, with no possibility of iteration, is the right thing to do. Never.
Waterfall has ALWAYS been an anti-pattern.
It has NEVER been a practice that ANYBODY advocated.
Yes, people started with design, then they implemented the design, and then they realized there were mistakes in the design, and sometimes, stupid people refused to admit this and change the design, and then they were called out, and told that that "the waterfall method is discredited" or something like this.
University instructors who "taught" the waterfall method were either grossly misinformed (as if this was considered an accepted practice in the real world), or, more likely, trying to make a point about the anti-pattern.
Perhaps you are unacquainted with the long, steady stream of failed enterprise projects. Many of these were build with the waterfall as the primary model. Should the project be successful, any "iterations" are called maintenance, often staffed with deliberatly junior people, with little or no access to the overall intent of the project. Maintenance is thought to be hideously expensive in this context, and rightly so.
So you have worked for (MS) and built organizations that have a far better idea of how to build software than the waterfall method, but believe that there are advocates who believe in the waterfall way of doing things. Fortunately it is becoming less frequent.
Yes. When maintenance is not considered something you do after you've built the software, but a part of the evolution of said software, you regularly see senior people fixing bugs and such.
[Waterfall] has NEVER been a practice that ANYBODY advocated.
I don't think you're quite right there. It was mandated by the US Department of Defense for years (DOD-STD-2167). Since they were (are?) the biggest software customer in the world, this was influential beyond the DoD.
Although there are a great many blog posts on this subject, they mostly (including this one) are uncredited paraphrases of Craig Larman's excellent research on the history of iterative development. It was Larman who figured out that Royce's original paper described waterfall as what not to do, Larman who figured out the history of how the DoD adopted it anyway (basically, they didn't read the second half of the paper), and Larman who tracked down the guy who had been responsible for that decision. IIRC, they met for lunch in Boston and his first words to Larman were "I'm so sorry!"
Waterfall has ALWAYS been an anti-pattern.
It has NEVER been a practice that ANYBODY advocated.
Yes, people started with design, then they implemented the design, and then they realized there were mistakes in the design, and sometimes, stupid people refused to admit this and change the design, and then they were called out, and told that that "the waterfall method is discredited" or something like this.
University instructors who "taught" the waterfall method were either grossly misinformed (as if this was considered an accepted practice in the real world), or, more likely, trying to make a point about the anti-pattern.