100% that.

Especially that working software over comprehensive documentation part, which can be automated so easily if done right.

There's so much value in TDD and providing a way to do integration and automated UI tests early on in a project, yet none of the companies I've worked at made use of it.

Also automated documentation tools like Swagger are almost criminally underutilised.

The other mistake everyone makes is "agile = faster and cheaper" . This results in corner cutting and unreasonable deadlines.

1. Hack together a proof of concept
2. Works well enough that management slaps a “done” sticker on it
3. Pile of hacks becomes load bearing
4. One or two dependencies change, the whole thing falls over
5. Set evenings and weekends on fire to fix it
6. Management brags about moving fast and breaking things, engineers quit and become cabbage farmers and woodworkers
7. New graduates are hired, GOTO 1

If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work

Or create a better UI that doesn't require so much documentation.

In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.

But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.

It wasn't, Waterfall in itself was a contrived example of a bad setup. More common was UP, or something UP-like.