> My take is that 70/80's built programs from a set of blueprints of what was required. Where each programmer had a set of requirements, knew what were required, when it is needed to be completed by and the tools available to enable the next level in development.
The thing is, you couldn't start dev until you had those blueprints. So that's a lot of time at the start of the project where development had to sit idle even if you had a good idea of what the architecture would at least be.
> If someone lagged behind then the project halted until but the end result was solidity and a completed application. At least during that time other programmers could improve their work and document.
No, you didn't get this. Apps that completed had bugs then too, whether in design, specification or implementation. It's why the waterfall paper basically said you'd have to built it twice either way, so you should try to accelerate building it the first time so you'd know what you messed up when you built it the second time.
Or as Mel Brooks, who wrote the Mythical Man-Month would say, "Build one to throw away; you will, anyhow."
Nor could programmers productively spend downtime simply document things, the documentation was supposed to have already been written by the time they were writing out punch cards. The "programming" had already been done, in principle, what remained was transcribing the processes and algorithms into COBOL or FORTRAN.
Startups are perfectly free to adopt the methods of the 70s if they wish, but they will be outcompeted and ground into dust in the process. Likewise, there is more to agile than Scrum (which is what you're describing with sprints), and it seems weird to describe the dread you'd get of blocking your team if it takes a week to do your part but act is if a week slip on the critical path in a waterfall effort is no big deal.
I mean, you're actually right that many (not all) waterfall-based teams treat it like it's no big deal, but that's the reason that waterfall projects were often disastrously over-time and over-budget. "We've already slipped 3 weeks to the right, what's another day?". Well, those add up... at least with agile you can more easily change the scope to fit the calendar, or adapt to changing market pressures, or more rapidly integrate learnings from user research.
More the 70s than 80s; our company wrote software in the mid 80s more or less the same as we (my company) still does; in the 80s-90s we just did ship a v1.0 a lot later than we do now, simply because in those times ages were basically impossible. Especially software on cardridges made it so you had to ship with 'no bugs'. But no blueprints; we just started on an idea we had and worked until it was good enough to ship.
> But no blueprints; we just started on an idea we had and worked until it was good enough to ship.
Yes, exactly. A lot of UNIX and other very good software for computers back then came about this way too. No or minimal blueprints and a lot of iterative implementation & testing and reacting to what you see.
It's hard convincing people today that agile methods have been in use long before sprints were a thing.
The thing is, you couldn't start dev until you had those blueprints. So that's a lot of time at the start of the project where development had to sit idle even if you had a good idea of what the architecture would at least be.
> If someone lagged behind then the project halted until but the end result was solidity and a completed application. At least during that time other programmers could improve their work and document.
No, you didn't get this. Apps that completed had bugs then too, whether in design, specification or implementation. It's why the waterfall paper basically said you'd have to built it twice either way, so you should try to accelerate building it the first time so you'd know what you messed up when you built it the second time.
Or as Mel Brooks, who wrote the Mythical Man-Month would say, "Build one to throw away; you will, anyhow."
Nor could programmers productively spend downtime simply document things, the documentation was supposed to have already been written by the time they were writing out punch cards. The "programming" had already been done, in principle, what remained was transcribing the processes and algorithms into COBOL or FORTRAN.
Startups are perfectly free to adopt the methods of the 70s if they wish, but they will be outcompeted and ground into dust in the process. Likewise, there is more to agile than Scrum (which is what you're describing with sprints), and it seems weird to describe the dread you'd get of blocking your team if it takes a week to do your part but act is if a week slip on the critical path in a waterfall effort is no big deal.
I mean, you're actually right that many (not all) waterfall-based teams treat it like it's no big deal, but that's the reason that waterfall projects were often disastrously over-time and over-budget. "We've already slipped 3 weeks to the right, what's another day?". Well, those add up... at least with agile you can more easily change the scope to fit the calendar, or adapt to changing market pressures, or more rapidly integrate learnings from user research.