[janpieterz]

Waterfall in software development was different than a Gantt chart based "project that was managed" like the construction of a bridge (an example close to my house). They added new requirements to this bridge (like they wanted the surrounding grounds to be maintained nicely, so added irrigation and gardening etc). But no new requirements were added to the foundational "here's a bridge and it needs to cross this stream from this point to that point" (high level).

Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up. That's where the anti-Gantt and "bad waterfall" comes from, the reality is the software world as a whole moves way quicker and requirements are way more malleable, subjective than building a bridge.

[colechristensen]

>Waterfall in software was continuously changing those fundamental parts. You'd be fine tuning the irrigation and needed to destruct the whole bridge because some new requirements came up.

Exactly this same thing also happens in non-software "waterfall" projects as well. Mid-project fundamental requirements changes which result in having to re-engineer large parts of the project. This is one of the reasons military acquisitions are so expensive, there's a huge problem with requirements changes.

[com]

And thus us why large-scale construction companies can bid so low, because most of their revenue and profit come from the inevitable scope and requirements changes later in the projects.

[janpieterz]

Perhaps to some degree, but I've never seen a skyscraper that was almost done being torn down to be re-architected and rebuilt.