It comes down essentially to that understanding. For well-understood problems waterfall might even be the best possible method.

It's only for not well understood problems that it fails so completely. In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall.

However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems.

The same is true for many other real life "waterfall" processes, like buildings, or bridges.

> In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall.

Or if the problem is that well-understood, there's an off-the-shelf solution so good nobody seriously thinks about re-implementing it.

> However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems.

Exactly. That's barely software development. That's using fully-commoditized components in well-understood fashions to achieve a well-understood goal.

You could script that. I'm sure some places have.

actually buildings and bridges aren't really waterfall the way they are designed. They have similar issues with changing requirements, new insights etc as the project progresses. The actual construction is not really the equivalent of writing code in this world.

And even during construction, you find new issues that you have to work around on any non trivial project.

Source: was a commercial interiors contractor before I was a software engineer.

Just because you either lucked out, or didn't have the testing to find what actually broke, doesn't make waterfall a good model.

The most well defined piece of software I know of, sel4, had a full machine checkable formal proof up front, and they still ran into issues during implementation that required them to go back and modify the spec.

You have a very extreme definition of waterfall. Waterfall doesn't mean that the spec is absolutely immutable. You will always find things to change in any effort of some complexity.

Yes it does, that's why it's called waterfall. Water doesn't flow back up the waterfall.

Do you take other words that literally too? Maybe they should have named waterfall "oioioihopjl" to avoid conflicts with other definitions?

Waterfall was a strawman, used in a paper as an ideally-bad project management strategy. The name was chosen on purpose to describe its fatal flaw.

Our industry being rather foolish, people read the paper and thought, 'hey, this sounds like a good idea!'

It's literally named waterfall in order to reference the idea that each step becomes immutable as it's being passed to the next step. This isn't some unfortunate consequence of an overstretched metaphor; it's literally the core concept.

It's not my fault that it appears you've been using the term wrong. Waterfall with feedback ceases to be waterfall.

I think the vast majority would take the term "waterfall" to mean "specifying software upfront before starting the build".

I don't think it really has anything to do with gravity.

Then go read the papers that these terms come from.

I have read the papers. Most people (ie, the "vast majority") have not.