3 ms·

Can you go into a bit more detail on your perspective of the 70s/80s approach vs. today? I’m an analyst with a passion for engineering, but am not an engineer b

by j_bum 1y ago

Can you go into a bit more detail on your perspective of the 70s/80s approach vs. today? I’m an analyst with a passion for engineering, but am not an engineer by trade. So honestly I am naive to how now would be different from the past.

doublerabbit 1y ago
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. 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. Meanwhile with agile, its always felt like a race to me. If you didn't complete your part then spend a whole week focusing on it while the others carry on with anticipation that the sprint will result in completion of the part required. Enabling for the next part they've built to be integrated. Vibe coding offers this "make a text box write to a file" code generation and it does. However without any blueprints the code starts to crumble when you proceed to introduce middleware such as authentication. It was never discussed on how authentication should authenticate because someone is already that far ahead in their work so you end up mashing more code together until it does work. It does and your product holds premise. The we'll improve, document and fix later never comes because of the influx of feature requests leading it to bloat. Now bogged down in tech debt you then spend resources in wrangling the mess with senior engineers. The senior engineers are now fixing the mess resulting in their experienced code not integrating with that of the juniors. The seniors now having to tidy that code leave behind the real code they were originally tasked in improving turning the whole codebase in to something that's a diabolical mess, but hey, it works. Hardware is cheaper than refactoring so instead you then "scale" by throwing more hardware at it until it handles the pressure. Someone then leaves and knowledge share is lost. Some exec promotes someone from the team who was crazy-sane enough to keep all in check to the senior role while skimping them on pay and are now handling the lost work, theirs and keeping the team in check. The product starts to fail and new junior engineers are bought in with new naive wisdom, jumping up and down with the newest fancy library tech finally making the process complete causing it to repeat itself indefinitely.
- mpyne 1y ago
  > 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.
  - anonzzzies 1y ago
    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.

by j_bum 1y ago

doublerabbit 1y ago

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. 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. Meanwhile with agile, its always felt like a race to me. If you didn't complete your part then spend a whole week focusing on it while the others carry on with anticipation that the sprint will result in completion of the part required. Enabling for the next part they've built to be integrated. Vibe coding offers this "make a text box write to a file" code generation and it does. However without any blueprints the code starts to crumble when you proceed to introduce middleware such as authentication. It was never discussed on how authentication should authenticate because someone is already that far ahead in their work so you end up mashing more code together until it does work. It does and your product holds premise. The we'll improve, document and fix later never comes because of the influx of feature requests leading it to bloat. Now bogged down in tech debt you then spend resources in wrangling the mess with senior engineers. The senior engineers are now fixing the mess resulting in their experienced code not integrating with that of the juniors. The seniors now having to tidy that code leave behind the real code they were originally tasked in improving turning the whole codebase in to something that's a diabolical mess, but hey, it works. Hardware is cheaper than refactoring so instead you then "scale" by throwing more hardware at it until it handles the pressure. Someone then leaves and knowledge share is lost. Some exec promotes someone from the team who was crazy-sane enough to keep all in check to the senior role while skimping them on pay and are now handling the lost work, theirs and keeping the team in check. The product starts to fail and new junior engineers are bought in with new naive wisdom, jumping up and down with the newest fancy library tech finally making the process complete causing it to repeat itself indefinitely.

mpyne 1y ago
> 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.
- anonzzzies 1y ago
  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.