> 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.
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.
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.
It was an illustrative example, but this is true for even things that are much more mundane. Maybe you'll come back and say that this is on builders or engineers taking shortcuts, but we could draw the analogy to programmers not using formal verification systems[0].
You are literally talking to someone who worked in that space and now works in software. How confident are you that you know more about that space than someone with years of professional experience? I'll add that I also have a degree in physics. My shift to software was through modeling and simulation of engineering designs. I'm sorry, I think you are overestimating your knowledge about rocket science. I'm pretty sure even in Russia they have "it's not rocket science" (or some equivalent) jokes.I promise you, your years of expertise in software makes you an expert in software, distinguishing you significantly from other experts. But I also promise you that this is true for any profession. Being an expert in physics doesn't make one automatically an expert in software. But the same is true in the other direction. You need to get your ego checked if you think differently.
[0] https://en.wikipedia.org/wiki/Formal_verification