zlacker

>>belter+(OP)
Every time I read about space engineering, I'm amazed by how contingencies have contingencies. It's so much careful planning and rigor compared to my world. I can always re-compile, re-deploy and regularly realize that my job is not life or death.

>>notyou+Bc1
Honestly, I'd say most engineering is like that outside of the software world. In the classic engineering disciplines with actual licensures at the end of the pipeline, the responsibility and ethics of this are ingrained into students from day 1. (Budget and importance of the application doesn't always allow for the indulgence of this though, at least to a point.)

This type of thinking also follows from decades of experience.

For some reason the software engineering world largely abandoned esteem and respect for all of the above.

>>Engine+pg1
Errors in software rarely ever matter and even when they do, can usually be trivially corrected.

>>throwa+zB1
Software does not wear out like most physical components, but they often cause failure in interaction/coordinating between subsystems.

As the amount of coordination increases, the number of failure modes tends to grow quite fast. That's why software failures in physical, safety-critical systems are not trivially corrected. There are a lot of second order effects that need to be considered.

>>bumby+AH1
> Software does not wear out like most physical components.

It fails like buildings near fault lines, because the ground moves under them. Think broken dependencies, operating system obsolescence, et cetera.

>>Qem+SO1
I like this analogy. Although your example focused on software-centric coordination, I think it's important to also extend it to non-software systems.

An apropos and famous example is the Ariane 5 rocket mishap. The same validated software from the Ariane 4 was used, but the hardware design changed. Specifically, the velocity of the Ariane 5 exceeded that of its predecessor and exceeded the 16-bit variable used.