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
Except when they do matter, like the Therac-25 deaths or those 737 MAX crashes.

>>crooke+HC1
> 737 MAX crashes

To imply this was a software bug is a pretty silly representation - the system was poorly engineered and didn't have proper contingencies for sensor disagreement. This is pretty clearly a design/engineering error with a software component.

Besides, the guy said "rarely ever matter" for a reason, not "explicitly never impact things"... Bit of a silly comment from you IMO

>>nawgz+VD1
To view software in isolation is an equally silly representation. In the physical world, software is part of an overall system that needs to be considered holistically. Most major safety-critical mishaps are the result of several failures, often across different domains.

In the case of the 737MAX, the software was a design around a physical constraint; that doesn't mean the software doesn't matter. Most software is designed as a workaround of a certain physical or mental constraint.