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 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!"