[zb]

The process you're describing is the Spiral Model, not the Waterfall. The major innovation of the Spiral Model was that you acknowledged that you would need to iterate - in the Waterfall days that was considered something to be embarrassed about.

The major innovation of Agile was that you acknowledged that the various steps of the Waterfall/Spiral happen at the same time - in the Spiral days, that was considered something to be embarrassed about.

I don't doubt, by the way, that you were taught that the Spiral Model was called Waterfall. But you should be aware that this was a case of historical revisionism on the part of whomever taught you.

[collyw]

It was a while ago, but I remember spiral being taught with a big spiral diagram - looked kind of like a snail shell. And waterfall had arrows that could go back up the way if needed.

I also remember being taught that errors caught after the software had been implemented was 100% more costly to fix than errors at the design stage - I think that was the idea behind big(ger) design up front.

https://sites.google.com/site/ucscsadg12/system-domain

[wpietri]

That "errors are more costly later" notion is true for waterfall, but not for, say, Extreme Programming.

It is basically true for waterfall because the feedback loops are broken. Think cooking, for example: if I cook all my meals for a year at once and put them in the freezer, I'll have to do a lot of research and planning. Otherwise, a single mistake could lead to me throwing out up to 1000 meals.

But if I just cook every meal as I go, I can tinker quite a bit, because the cost of failure is limited to one meal. Which is no problem; if I really screw up, I just pull the frozen pizza out of the fridge.

Extreme Programming in particular can be looked at as a set of methods to flatten the cost of change curve. Then if you add the Lean Startup approach on top of that, you end up testing your core hypotheses early on, so even major shifts in business direction end up being pretty inexpensive.