← Back to context

Comment by godelski

1 month 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.

> 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.

  • > 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.

    • > You had to take action to receive them.

      What did that look like? Remember, back then, developers and users often had no after-sale communications at all. It was a technical impossibility more than anything. There was paper mail. There were telephone networks. That's about it.

      I suppose you could occasionally call the developers of every software product you're using to ask if there is an update. I doubt anyone ever did that.

      10 replies →

    • > 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

      6 replies →

> 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.

  •   > 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

    [1] https://space.stackexchange.com/questions/10022/who-coined-t...

    [2] https://en.wikipedia.org/wiki/Software_rot

    • > 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.

      1 reply →