Waterfall represents the default approach to managing chaos. One or two programmers with a single customer have an easy time getting a job done. When the budget gets into the millions, the project fails from having too many chefs in the kitchen, etc. So the gut reaction is to overload the front end with process. Finish requirements first, create a high level design, split it up into components that can be implemented, create a detailed design for each component, implement the design, integrate, test. I heard a ton of times as a consultant from average people, "we needed to specify more of this up front and create better designs ahead of implementation."
It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. You don't have to follow an agile methodology to acheive a successful project, but you do have to have feedback loops that reduce the risk of wasted effort.
In the engineering analogy, I like to tell people that the compiler is the builder. All coding is an exercise in architecture and engineering that produces a detailed design (the code).
I've seen too many projects where the specification guys were basically writing the whole program suite in English and then expecting it to just translate smoothly to computer code.
Then their beautiful 5 year late 2000 page specification slams head first into the realities of computers and the project immediately becomes quagmired. It's basically the Soviet model of computer programming, where you try to make all of the design decisions from the top but the people at the top don't have the whole picture and can't make good decisions and the scope is way too large for mere mortals to learn enough to make said decisions.
> It doesn't work this way because software development is the process of figuring out the actual requirements and a good design.
In my experience very few people truly understands why engineering is something expensive at its core, and it's usually this particular lack of understanding that ironically ends up making making things even more expensive and produces worse value-for-money, and so the vicious cycle continues.
It doesn't work this way because software development is the process of figuring out the actual requirements and a good design. You don't have to follow an agile methodology to acheive a successful project, but you do have to have feedback loops that reduce the risk of wasted effort.
In the engineering analogy, I like to tell people that the compiler is the builder. All coding is an exercise in architecture and engineering that produces a detailed design (the code).