>> Analysis, Specifications, Requirement >These tend to be inadequate, incomplete, or .. >> Qualification >.. at this point the customer discovers that what they asked for does not actually solve their problem.

I disagree. If you are properly isolating your work into an "Analysis" phase, you will properly flesh out the issues and the subsequent specifications and requirements will be complete - sufficient to the task of formulating a development/implementation plan. But if you don't take care to complete a proper analysis - then no, you won't formulate specs or req's properly, either.

The important thing is that the individuals involved know the value of a proper analysis - whether they are developers or managers or just paying the bills. Too often, software developers don't realize that they are really providing a social service, and thus they don't deliver proper analyses that can result in action. Alas, that is something other than a tooling/methodology issue and lays more in the motivations of the developer.

Its a lot easier to say you can't be responsible for the mess as a developer if you don't allow the mess to be adequately described, in the first place .. so the Agile vs. Waterfall debate is really more of an ethics issue than anything else.

Good developers do Waterfall Complete. Mediocre developers do it, and call it Agile. Terrible developers find excuses for not doing the key things, and end up with a failed project on their hands.

> If you are properly isolating your work into an "Analysis" phase, you will properly flesh out the issues and the subsequent specifications and requirements will be complete - sufficient to the task of formulating a development/implementation plan. But if you don't take care to complete a proper analysis - then no, you won't formulate specs or req's properly, either.

But what if that doesn't happen?

(This seems to parallel the "C is safe if you don't write bugs" argument. Processes that require infallibility are bad processes.)

The level of dysfunctionality that can be achieved is baffling. How can someone fail to deliver a payroll system? https://www.smh.com.au/technology/worst-failure-of-public-ad... - it's one of the oldest applications of business computing, and yet somehow it wastes a billion Australian dollars?

>Australian dollars

Perhaps Waterfall (and its cousins) needs an addendum: Check for and Remove Corruption.

Honestly it's mostly incompetence that is the problem and waterfall magnifies incompetence.

Incompetent waterfall magnifies incompetence.

Competent waterfall results in finished software projects.

If the Analysis has been done properly and we are sure that it has left no room for error, and if we demand similar quality from the Specification and other phases, then why do we need a Qualification phase at the end at all?

Conversely, if we accept that each phase is fallible so Qualification is crucial for any chance at a good working product, what is the recourse for errors in the Analysis phase? Basically if there was an error in the Analysis phase, we will, by definition, only find it in the Qualification phase, requiring us to scrap all of our work and start over from a new Analysis phase.

Of course no one is doing the Analysis properly. It's impossible. You plan how to implement something using a library method. But only in the qualification phase you find out that this method actually has a bug on your target platform or is incompatible with another part of your software.

I dunno, I've seen many, many examples of a properly done Analysis phase. But it does require a great deal of competence, a lack of hubris, and plenty of self-doubt/verification/validation on the part of technical contributors to make sure they do actually know what they're talking about .. a Qualifications step usually reveals the nature of this impact on the project - or lets just say, omitting this step is usually the first part of project failure.

Your comment is the most accurate assessment of the history. It’s good for people to know.