Same here. Just 10 years ago I had the displeasure of working on such a project. Months and months of upfront specification work. The UX was defined in full separately from the UI. All the DB models built in one go. Every Gantt cascade one could imagine. Horizontal slice by horizontal slice. The system was to be fully integrated at the very end, followed by a few weeks of QA.
If anyone doubts that waterfall was the dominant approach to development and project management, just go back to the tools of the times, like Microsoft Project. Gantt charts were the unquestioned way you managed a project.
It was definitely the dominant conceptual approach, but I think it's an open question how much it was actually followed versus just being the lies everybody agreed to tell the executive caste.
One way I've weaned people off waterfall approaches is just to tell them yes, of course that's what we're doing, but to make it extra safe, we'll produce software early and often so you can see progress. Then eventually I'll slip in getting users to try it, just for "testing". And then getting it deployed early, for more "testing". The smart ones get engaged in this process, using it to making things better than the initial conceptions. They may produce waterfall documents for a while, especially if they need to pacify higher ups. But often they'll just forget. I think them GANTT charts and the like were always a ritual to get them feelings of control, and they stop doing that work once they have actual control.
So I suspect a lot of the nominal waterfall projects of yore were similarly made to work by developers just doing the right thing in quiet ways while saying, "Oh, that's 90% complete for sure. Mark it on your chart!"
Something similar happened to flow charts. They get unreadable after a few tens of LOC, but the managers required them. So people dutifully shipped tons of paper upstairs, and nobody ever read them. Then they were drawn after the source was written, instead of before. Then a computer program generated them straight from the source code. Then they stopped printing them, storing them on disk instead. Then the flow chart generator broke, and nobody noticed the write-only documentation was missing. Finally, some manager got the genius idea to speed up the process by not requiring flow charts anymore.
This kinda reminds me of a middle school English teacher I had who insisted on receiving both a rough draft and (a couple days later) a final draft, which had to be different, because there had to be at least some grammar/spelling mistakes in the first draft.
I was a kid who didn't make grammar/spelling mistakes. I'd just write up the paper, insert two or three errors, submit it, and then a couple days later submit the original version.
Hmm, here as well. But then would reorganize the sentences, and add details, where I think the most value of another draft is. Fixing spelling mistakes never entered my mind.
>It was definitely the dominant conceptual approach, but I think it's an open question how much it was actually followed versus just being the lies everybody agreed to tell the executive caste.
Its funny because that would the inverse of the current situation where exec proclaims their company is agile to external observers and potential hires, but the de facto regime could be anything
Great point. And in those faux-Agile environments, you'll definitely sometimes find people just doing the right thing and then finding the right way to lie to JIRA about it.
One company I worked with we switch over from waterfall to agile. The 'guardian' of the rooms of paperwork was so happy when she could bin 2 rooms full of filing cabinets overflowing with designs no one really followed. Took her about a week to clear it all out. Hundreds of rolls of gantt charts dumped into a recycle dumpster. Basically we stopped pretending we were not redesigning everything as we went along.
I worked professionally from the late 90s. We used Gantt, but it was always for spiral or unified process. We were always told to avoid waterfall (as there’s a natural tendency to go that way) and always include feedback loops.
There's a reason why construction and other projects that require coordinating with external parties rely on Microsoft project so much.
I'm on a project now trying to manage external customer cutovers and integrations using JIRA and its a dumpster fire.
A proper project plan with deadlines, lead times, resources etc would solve 99% of the problems.
Its just non stop crisis "oh we forgot to get get change submitted on time" - "oh this customer can't migrate until date x" - "oh this test environment is down for scheduled rebuild on days xyz" - all can easily be tracked to automatically calculate timelines.
Agile is fine at a macro level, but it needs to feed into a better system for real world dependencies and deadlines.
Naturally nothing worked and everything was late.