I wish most software engineers were even half as attentive to detail as most traditional engineers are when it comes to failure modes. The field is obsessed with the happy path which in my opinion separates it from “actual” engineering didciplines.
1. Computer programs are far more complex (and complex in a hard to analyze way) than mechanical systems
2. Programming is (still) a relatively immature field, and, and a result, it doesn't have the institutional knowledge and best practices that make certain failure modes highly unlikely
I think (2) is an underappreciated point. If you look at the history of e.g. boilers and steam engines, the early years are absolutely rife with examples of boilers and steam engines exploding in spectacular ways, often killing people in the process. It took years for standards of design and engineering to develop which made those failures exceedingly unlikely. Another example comes from aeronautical engineering. The Comet jetliner, for example, suffered from cracks that developed due to metal fatigue that was exacerbated by the design of the windows. These cracks led to crashes that killed hundreds, and, in response, standards were created and modified to ensure that window frames were properly designed and reinforced to prevent cracks from propagating. Furthermore, Dan Luu has done some work [1] in analyzing how cars fare in accident types that haven't been incorporated into safety standards, and he finds that their performance is often quite bad.
Most "traditional" engineering is like that. It's not that the engineers are personally paying more attention to failure modes. It's that they're following standards, and as long as the standards are followed, the failures that necessitated the creation of those standards are prevented. Programming, unfortunately, is still new enough that many of the standards we need haven't yet been developed, and most practicioners are new enough to the field that what standards do exist haven't really propagated across the field.
[1]: https://www.hillelwayne.com/post/are-we-really-engineers/
Some upfront thinking would help us (developers) save a lot of effort and frustration
And, obviously, software is in charge of actual security in the real world, and the track record there is not exactly flattering! Safety as well, of course, but luckily safety-critical software is a much smaller and usually more rigorous subfield, quite unlike the case with security.
Last time i had to get roadside assistance, they couldn't use a mile marker / highway location reference. They had to have something to type into google maps in order to dispatch help.
Could they have gotten to me if google maps was down? Probably but i'm not sure. Either way, it wouldn't have been the practiced default and that matters.