It's amazing how many times over my career I've watched and participated in debates on software development methodologies. HN seems to have one at least annually.
The author of the post does a good job summing up the issues. I only skimmed it but have to agree with everything I read.
I can add that there's a time and place for Waterfall: when requirements are well-known and static and when lots of oversight is needed. I can also add that no methodology has successfully dealt with the mega-projects we read about in software engineering case studies.
Building stuff, whether it's software or anything other product, is hard. It's messy. Often the requirements are not well thought out. In the situations I normally deal with, a requester can state a high-level strategic goal for the organization, but not how the software can get us to it. That's where my team gets involved. One engineer I respect highly once said that we need to get something in front of the requester quickly so that we can find out what (s)he doesn't want. By process of elimination, the idea foments in the requester's mind and requirements become more concrete.
Again, though, some organizations are very static or they deal with software whose failure can be catastrophic. In those situations, the highly bureaucratic Waterfall method can be helpful at least for slowing down the process.
I think the "Mythical Man-Month" does a great job accounting for the process and implementation of a mega-project. But as Brooks even stated, there's "No Silver Bullet."
The author of the post does a good job summing up the issues. I only skimmed it but have to agree with everything I read.
I can add that there's a time and place for Waterfall: when requirements are well-known and static and when lots of oversight is needed. I can also add that no methodology has successfully dealt with the mega-projects we read about in software engineering case studies.
Building stuff, whether it's software or anything other product, is hard. It's messy. Often the requirements are not well thought out. In the situations I normally deal with, a requester can state a high-level strategic goal for the organization, but not how the software can get us to it. That's where my team gets involved. One engineer I respect highly once said that we need to get something in front of the requester quickly so that we can find out what (s)he doesn't want. By process of elimination, the idea foments in the requester's mind and requirements become more concrete.
Again, though, some organizations are very static or they deal with software whose failure can be catastrophic. In those situations, the highly bureaucratic Waterfall method can be helpful at least for slowing down the process.