The one thing waterfall did that I think was actually quite a good thing, at least for larger scale problems, was 'preliminary design'.
Experience shows it's really important to get 'the bones' of your system right, as early on as possible. Working to produce a preliminary design in an abstract space rather than in code frees you at this early stage from the inertia of code. It's easier to throw out a set of block diagrams and start over precisely because, as mere diagrams, they don't "sort of work already". And I'm certain that in the history of waterfall projects, nobody anywhere ever went off 'on the side' to knock out a prototype as an 'evaluation exercise', now did they?
That said, re the rest of waterfall? Not sure I'm missing that.
I'm not talking block diagrams here. I'm talking about fully fleshing out issues down to the level of functions inputs and outputs(1). So that managers will be pleased with the "planning" and "sizing" and some other buzzwords...
(1) Which (outputs) are another bitter story since we are building on top of legacy code that is working with side effects from head to toes. But let's not touch this can of worms.
Yeah, that's nuts. That's way beyond where even the 'detailed design' phase should go. I've been on projects where DD has delved to the level of identifying individual classes, and I think even that's a bit of a reach. But managers do love their metrics.
Experience shows it's really important to get 'the bones' of your system right, as early on as possible. Working to produce a preliminary design in an abstract space rather than in code frees you at this early stage from the inertia of code. It's easier to throw out a set of block diagrams and start over precisely because, as mere diagrams, they don't "sort of work already". And I'm certain that in the history of waterfall projects, nobody anywhere ever went off 'on the side' to knock out a prototype as an 'evaluation exercise', now did they?
That said, re the rest of waterfall? Not sure I'm missing that.