  > 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

▲ grishka 8 days ago | parent [-]

> 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 8 days ago \| parent [-]
		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]. `> But then again, comparing rockets to software is unfair. Rockets have a finite scope.` 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