4 ms·

> I don't think software is ever finished. Back when it came on physical media, it was very much finished. Needing an update to fix a critical bug or a UX issu

> I don't think software is ever finished. Back when it came on physical media, it was very much finished. Needing an update to fix a critical bug or a UX issue was a very costly problem to have, both in money and in reputation. Users had to be convinced to buy and install major updates, instead of being strong-armed into it. Staying on an older version was easier, and in case of operating systems, much more widely accepted. Many video games fall into that category even today. Sure, the "we can always release an update" mentality did infest game developers as well, but, unlike apps and OSes, most games do have a finite scope and stop being developed once that scope has been realized.

godelski 1y ago
> Back when it came on physical media, it was very much finished. That's also not true and I think you're not reading my point fairly. Back when software came on physical media we still had patches. We had patches that came through the internet and we had patches that came through physical media. The latter making it harder to patch. It's a great situation when a bug is discovered and it is hard to patch. You're fantasizing about a time that never existed. Software isn't "ever finished" because we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable. That's the mindset that "all tests pass" or "it works for me" means the software "works." We can't address the problems, as discussed in the article and that I mentioned in my comment, if we're going to retcon history and redirect ourselves to a worse environment. That doesn't fix anything. We'll never be omniscient, sorry. The world changes. Hardware changes. Software rots. Time marches on. These do not change and we have to operate in a world where we acknowledge these basic facts of reality. We'll never make decent software if we can't acknowledge reality first.
- palata 1y ago
  > Back when software came on physical media we still had patches. We had patches that came through the internet and we had patches that came through physical media. Did you live at a time where Internet was not a thing? I remember very clearly buying software on physical media and never, ever "receiving" a single patch. I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"? I remember being able to buy "the next version", though. But the expectation was that I was buying a "finished" version, not something unfinished that required me to buy all the next versions.
  - mechanicalpulse 1y ago
    > Did you live at a time where Internet was not a thing? You must be relatively young. Software existed before the widespread adoption of the Internet. > I remember very clearly buying software on physical media and never, ever "receiving" a single patch. You had to take action to receive them. They weren’t automatic updates like they are today. > I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"? That’s exactly what it looked like. That’s still the process today for some systems —- avionics updates for Boeing 747s are provided on 3.5” floppies.
    - palata 1y ago
      > You must be relatively young. Did you read my comment at all? :-) > You had to take action to receive them. They weren’t automatic updates like they are today. Are you saying I was doing it wrong? > updates for Boeing 747s Oh I get it. Maybe we just weren't playing with the same toys :D
      - godelski 1y ago
        > Did you read my comment at all? :-) Did you read *MY* comment at all?! Everything @mechanicalpulse said was accurate. To answer @grishka's question (because it seems you also don't know) > What did that look like? Well I literally answered that in my comment! >>> Back when software came on physical media we still had patches. We had patches that came through the internet AND WE HAD PATCHES THAT CAME THROUGH PHYSICAL MEDIA. THE ***LATTER*** MAKING IT ***HARDER TO PATCH.*** I broke it up and emphasized the key parts. If you are going to accuse someone of not reading your comment you damn well better be reading the comments you're responding to. > Oh I get it. Maybe we just weren't playing with the same toys Considering it was "harder to patch", yes, it does also mean "things often went unpatched." Mind you, this doesn't mean patches didn't exist nor does it mean, as you suggest, patches don't matter. But again, I already addressed that in my original comment, so I'm not going to repeat myself again...
        1y ago
- grishka 1y ago
  > we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable We can come close to that in all other areas of engineering, but somehow not software? We can build buildings and bridges and be certain that they won't collapse. We can engineer machines that work reliably and safely. But for some reason we can't do the same for software? I call bullshit. > Hardware changes. And operating systems do need to be updated for that sometimes, sure. They would even sometimes need to expose new APIs to apps, so the apps could make use of new hardware capabilities. However, there isn't much reason to update an OS on existing hardware. Especially when all that update does is bring a new stupider UI design that no one asked for. > Software rots. What the heck do you even mean by that? Software is a sequence of CPU instructions. It can't "rot". It's the runtime environments that rot for no good reason.
  - godelski 1y ago
    > We can come close to that in all other areas of engineering, but somehow not software? I worked as an Aerospace Engineer before I moved to software. What the absolute fuck are you talking about? Physically engineered stuff fails all the time. Look, March of *THIS YEAR* (2025) SpaceX had a rocket *EXPLODE*[0]. Rapid unscheduled disassembly[1] does not indicate we can "foresee all problems and fix all bugs". In fact, it indicates the *exact opposite*. There is absolutely no field where we've become omniscient. To think we are is just laughable! But if you want to know why physical engineering tends to be more robust, you might want to take an engineering class. You'll find that the way they do things is... a bit different... There's a lot more verification and testing. >> Software rots. > What the heck do you even mean by that? It is an old, yet common, phrase that encompasses a wide range of issues that result in "no changes were made, but now the program doesn't work"[2] [0] https://www.bbc.com/news/articles/cj92wgeyvzzo https://www.bbc.com/news/articles/cj92wgeyvzzo [1] https://space.stackexchange.com/questions/10022/who-coined-the-phrase-rapid-unscheduled-disassembly https://space.stackexchange.com/questions/10022/who-coined-t... [2] https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
    - grishka 1y ago
      > Look, March of THIS YEAR (2025) SpaceX had a rocket EXPLODE[0]. It's a Starship. It's still in development. It's not a finished product like Falcon. And it's not an unexpected outcome either — after all, SpaceX is doing something that no one has done before, so there does not exist any prior knowledge about the behavior of rockets this huge, and especially reusable. They aren't failing, they are making this knowledge so they could build a rocket that does not explode. But then again, comparing rockets to software is unfair. Rockets have a finite scope. They go up to safely put things or people into space. In case of SpaceX, they also preferably come back down in one piece to be reused. The more specific requirements only change as a response to new discoveries in the development and testing process — not because some manager has nothing to do, or infinite exponential growth needs to be shown, or investors are demanding AI to be shoehorned into every product, or some designer is desperate for promotion. > no changes were made, but now the program doesn't work Some changes for sure were made, because otherwise that would violate the core principle of computer science that the same algorithm executed with the same inputs will always yield the same exact result.

godelski 1y ago

> Back when it came on physical media, it was very much finished. That's also not true and I think you're not reading my point fairly. Back when software came on physical media we still had patches. We had patches that came through the internet and we had patches that came through physical media. The latter making it harder to patch. It's a great situation when a bug is discovered and it is hard to patch. You're fantasizing about a time that never existed. Software isn't "ever finished" because we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable. That's the mindset that "all tests pass" or "it works for me" means the software "works." We can't address the problems, as discussed in the article and that I mentioned in my comment, if we're going to retcon history and redirect ourselves to a worse environment. That doesn't fix anything. We'll never be omniscient, sorry. The world changes. Hardware changes. Software rots. Time marches on. These do not change and we have to operate in a world where we acknowledge these basic facts of reality. We'll never make decent software if we can't acknowledge reality first.

palata 1y ago
> Back when software came on physical media we still had patches. We had patches that came through the internet and we had patches that came through physical media. Did you live at a time where Internet was not a thing? I remember very clearly buying software on physical media and never, ever "receiving" a single patch. I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"? I remember being able to buy "the next version", though. But the expectation was that I was buying a "finished" version, not something unfinished that required me to buy all the next versions.
- mechanicalpulse 1y ago
  > Did you live at a time where Internet was not a thing? You must be relatively young. Software existed before the widespread adoption of the Internet. > I remember very clearly buying software on physical media and never, ever "receiving" a single patch. You had to take action to receive them. They weren’t automatic updates like they are today. > I don't even know how that would have looked... "buy this floppy disk, it's a patch for a bug in the other floppy disk you bought recently"? That’s exactly what it looked like. That’s still the process today for some systems —- avionics updates for Boeing 747s are provided on 3.5” floppies.
  - palata 1y ago
    > You must be relatively young. Did you read my comment at all? :-) > You had to take action to receive them. They weren’t automatic updates like they are today. Are you saying I was doing it wrong? > updates for Boeing 747s Oh I get it. Maybe we just weren't playing with the same toys :D
    - godelski 1y ago
      > Did you read my comment at all? :-) Did you read *MY* comment at all?! Everything @mechanicalpulse said was accurate. To answer @grishka's question (because it seems you also don't know) > What did that look like? Well I literally answered that in my comment! >>> Back when software came on physical media we still had patches. We had patches that came through the internet AND WE HAD PATCHES THAT CAME THROUGH PHYSICAL MEDIA. THE ***LATTER*** MAKING IT ***HARDER TO PATCH.*** I broke it up and emphasized the key parts. If you are going to accuse someone of not reading your comment you damn well better be reading the comments you're responding to. > Oh I get it. Maybe we just weren't playing with the same toys Considering it was "harder to patch", yes, it does also mean "things often went unpatched." Mind you, this doesn't mean patches didn't exist nor does it mean, as you suggest, patches don't matter. But again, I already addressed that in my original comment, so I'm not going to repeat myself again...
      - 1y ago
grishka 1y ago
> we are not omniscient writers who can foresee all problems, fix all bugs, and write software that is unhackable We can come close to that in all other areas of engineering, but somehow not software? We can build buildings and bridges and be certain that they won't collapse. We can engineer machines that work reliably and safely. But for some reason we can't do the same for software? I call bullshit. > Hardware changes. And operating systems do need to be updated for that sometimes, sure. They would even sometimes need to expose new APIs to apps, so the apps could make use of new hardware capabilities. However, there isn't much reason to update an OS on existing hardware. Especially when all that update does is bring a new stupider UI design that no one asked for. > Software rots. What the heck do you even mean by that? Software is a sequence of CPU instructions. It can't "rot". It's the runtime environments that rot for no good reason.
- godelski 1y ago
  > We can come close to that in all other areas of engineering, but somehow not software? I worked as an Aerospace Engineer before I moved to software. What the absolute fuck are you talking about? Physically engineered stuff fails all the time. Look, March of *THIS YEAR* (2025) SpaceX had a rocket *EXPLODE*[0]. Rapid unscheduled disassembly[1] does not indicate we can "foresee all problems and fix all bugs". In fact, it indicates the *exact opposite*. There is absolutely no field where we've become omniscient. To think we are is just laughable! But if you want to know why physical engineering tends to be more robust, you might want to take an engineering class. You'll find that the way they do things is... a bit different... There's a lot more verification and testing. >> Software rots. > What the heck do you even mean by that? It is an old, yet common, phrase that encompasses a wide range of issues that result in "no changes were made, but now the program doesn't work"[2] [0] https://www.bbc.com/news/articles/cj92wgeyvzzo https://www.bbc.com/news/articles/cj92wgeyvzzo [1] https://space.stackexchange.com/questions/10022/who-coined-the-phrase-rapid-unscheduled-disassembly https://space.stackexchange.com/questions/10022/who-coined-t... [2] https://en.wikipedia.org/wiki/Software_rot https://en.wikipedia.org/wiki/Software_rot
  - grishka 1y ago
    > Look, March of THIS YEAR (2025) SpaceX had a rocket EXPLODE[0]. It's a Starship. It's still in development. It's not a finished product like Falcon. And it's not an unexpected outcome either — after all, SpaceX is doing something that no one has done before, so there does not exist any prior knowledge about the behavior of rockets this huge, and especially reusable. They aren't failing, they are making this knowledge so they could build a rocket that does not explode. But then again, comparing rockets to software is unfair. Rockets have a finite scope. They go up to safely put things or people into space. In case of SpaceX, they also preferably come back down in one piece to be reused. The more specific requirements only change as a response to new discoveries in the development and testing process — not because some manager has nothing to do, or infinite exponential growth needs to be shown, or investors are demanding AI to be shoehorned into every product, or some designer is desperate for promotion. > no changes were made, but now the program doesn't work Some changes for sure were made, because otherwise that would violate the core principle of computer science that the same algorithm executed with the same inputs will always yield the same exact result.