3 ms·

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 wit

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.

hilbertseries 4y ago
It’s all about risk profiles. The failure of a bridge or an airplane is catastrophic and people will die. If a SaaS provider is down for awhile, people are frustrated.
- monsieurbanana 4y ago
  You're right, it's just an inconvenience for the users, but a real problem for the developpers. Some upfront thinking would help us (developers) save a lot of effort and frustration
  - keithly 4y ago
    It’s not just the developers, but the entire organizations they work within that prioritize shipping new features rather than reliability, because that’s generally what’s most profitable (at least in the short term). It’s hard to change those incentives for an entire organization.
- Sharlin 4y ago
  The impact, whether economic or QoL or whatever metric you prefer to use, of a million frustrated people and the corresponding loss of productivity may not be insignificant. 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.
- jetpks 4y ago
  I think this used to be true, but we're not building toys anymore. Whether we like it or not, SaaS products are rapidly becoming transitive dependencies of mission critical, life/death infrastructure. 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.
quanticle 4y ago
I think the perception that programmers are less attentive to failure modes than other engineers is an artifact of two things: 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://danluu.com/car-safety/ https://danluu.com/car-safety/
- quanticle 4y ago
  Along this theme, Hillel Wayne has a series of blog posts [1] [2] [3], where he argues that programming and engineering aren't really that far removed from each other, and, surprisingly, in some ways programming is more advanced than "traditional" engineering. [1]: https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/ [2]: https://www.hillelwayne.com/post/we-are-not-special/ https://www.hillelwayne.com/post/we-are-not-special/ [3]: https://www.hillelwayne.com/post/what-we-can-learn/ https://www.hillelwayne.com/post/what-we-can-learn/
deleted 4y ago
[deleted]
nikau 4y ago
Lost count of the number of devs who think a whole function inside a 'try' block with print(e) as the exception handler is the gold standard.

hilbertseries 4y ago

It’s all about risk profiles. The failure of a bridge or an airplane is catastrophic and people will die. If a SaaS provider is down for awhile, people are frustrated.

monsieurbanana 4y ago
You're right, it's just an inconvenience for the users, but a real problem for the developpers. Some upfront thinking would help us (developers) save a lot of effort and frustration
- keithly 4y ago
  It’s not just the developers, but the entire organizations they work within that prioritize shipping new features rather than reliability, because that’s generally what’s most profitable (at least in the short term). It’s hard to change those incentives for an entire organization.
Sharlin 4y ago
The impact, whether economic or QoL or whatever metric you prefer to use, of a million frustrated people and the corresponding loss of productivity may not be insignificant. 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.
jetpks 4y ago
I think this used to be true, but we're not building toys anymore. Whether we like it or not, SaaS products are rapidly becoming transitive dependencies of mission critical, life/death infrastructure. 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.

quanticle 4y ago

I think the perception that programmers are less attentive to failure modes than other engineers is an artifact of two things: 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://danluu.com/car-safety/ https://danluu.com/car-safety/

quanticle 4y ago
Along this theme, Hillel Wayne has a series of blog posts [1] [2] [3], where he argues that programming and engineering aren't really that far removed from each other, and, surprisingly, in some ways programming is more advanced than "traditional" engineering. [1]: https://www.hillelwayne.com/post/are-we-really-engineers/ https://www.hillelwayne.com/post/are-we-really-engineers/ [2]: https://www.hillelwayne.com/post/we-are-not-special/ https://www.hillelwayne.com/post/we-are-not-special/ [3]: https://www.hillelwayne.com/post/what-we-can-learn/ https://www.hillelwayne.com/post/what-we-can-learn/

deleted 4y ago

[deleted]

nikau 4y ago

Lost count of the number of devs who think a whole function inside a 'try' block with print(e) as the exception handler is the gold standard.