5 ms·

> I'm often surprised how little discussion I see of failure analysis and especially failure design is in software engineering. It is one of the most important

> I'm often surprised how little discussion I see of failure analysis and especially failure design is in software engineering. It is one of the most important concepts in engineering, but I guess we still operate like software can't kill you. This is a major reason why many "traditional" engineers do not consider programmers to be true engineers.

godelski 3y ago
Yeah the jokes tend to be about how little concern there is for quality control or things breaking. I'm a fan of "move fast and break things" for getting things started and new projects but I'm not sure why that mentality continues into mature products. I think a lot of software dev teams would benefit from referencing the TRL system[0]. I did work as an engineer in a aerospace startup and you definitely move fast and hack a lot at low TRL but you treat mid TRL very differently. Helps to keep scope and pull away from these 26 "2 week sprint" nonesense. Doesn't make sense for mature products, you're just going to break things that already work. Now I will add though that it isn't uncommon for "traditional" engineers to also move too slowly. I think there's a balance in there. Don't be Boeing but don't be a startup either if you're Google. [0] https://en.wikipedia.org/wiki/Technology_readiness_level https://en.wikipedia.org/wiki/Technology_readiness_level
- mewpmewp2 3y ago
  Does it not matter what the consequences of failure are to determine how much effort should be put into handling failure?
  - syndicatedjelly 3y ago
    Of course it matters. That’s the “end effect” portion of any proper risk management process. The severity and likelihood of various end effects drives improvement in the design, creation, and usage of the item.
    - mewpmewp2 3y ago
      But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Most of the time physical devices failing will have much more severe consequences, than a website going down for an hour. In some cases there are APIs which many other critical systems use and frequently those APIs do have much more rigorous process in making sure that they are reliable. All of that seems regulated by governments and markets to me. They have promises of reliability and big financial penalties if they were to fail on that reliability.
      - godelski 3y ago
        > But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Because the traditional engineers do this in a lot of stuff and not just high risk domains. You can probably find somewhere an FEA analysis on your TV's legs and where the high stress points are and where it'll break. > They have promises of reliability and big financial penalties if they were to fail on that reliability. Ehhhhh really? Or if everyone does a shit job do we just take it? Most people aren't tech literate. Hell, most apps aren't built by tech literate people. I have a laundry app I have to use and the rooms aren't in any logical order, just randomly placed. Are you tech literate if you don't know a sort function exists? Or if you don't know people like to read things in a sorted order? If you can't google the answer? There's lots of systems that have really shit designs in them and as discussed elsewhere in the thread I don't think companies are having big financial consequences for their lightbulbs not working when the wifi goes down because the people purchasing them aren't aware that such a insane thing would happen. If you're not very tech literate you wouldn't even think that's a possible outcome. So don't just rely on markets because econ 101 isn't enough.
      - syndicatedjelly 3y ago
        > But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Outside of engineering, few people have ever even heard the phrase “risk management”, let alone understand the theory behind it. It’s really hard to argue that a developer can consider themself an engineer, when they don’t bother understanding what happens when the thing they “engineered” fails. Yes this applies to web applications too. If someone can’t access an application that gives them directions, it’s possible that they will be stranded. If a healthcare website fails to load a list of available physicians, it’s possible the user gives up and doesn’t seek medical care. The current prevailing attitude in web dev of “who cares” is really a testament to how little most web developers and real engineers have in common. Software engineers working on safety-critical systems deserve that title because they actually have to understand software risks, design appropriate mitigations, and prove their effectiveness.
  - godelski 3y ago
    That's actually the entire point. There's consequences to however anything fails. Think the skyscraper example. Do you want to explicitly design a failure mode or do you want to be just "let's see what happens?" Which do you think has a worse consequence? Neither are great, but one is definitely better than the other.

godelski 3y ago

Yeah the jokes tend to be about how little concern there is for quality control or things breaking. I'm a fan of "move fast and break things" for getting things started and new projects but I'm not sure why that mentality continues into mature products. I think a lot of software dev teams would benefit from referencing the TRL system[0]. I did work as an engineer in a aerospace startup and you definitely move fast and hack a lot at low TRL but you treat mid TRL very differently. Helps to keep scope and pull away from these 26 "2 week sprint" nonesense. Doesn't make sense for mature products, you're just going to break things that already work. Now I will add though that it isn't uncommon for "traditional" engineers to also move too slowly. I think there's a balance in there. Don't be Boeing but don't be a startup either if you're Google. [0] https://en.wikipedia.org/wiki/Technology_readiness_level https://en.wikipedia.org/wiki/Technology_readiness_level

mewpmewp2 3y ago
Does it not matter what the consequences of failure are to determine how much effort should be put into handling failure?
- syndicatedjelly 3y ago
  Of course it matters. That’s the “end effect” portion of any proper risk management process. The severity and likelihood of various end effects drives improvement in the design, creation, and usage of the item.
  - mewpmewp2 3y ago
    But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Most of the time physical devices failing will have much more severe consequences, than a website going down for an hour. In some cases there are APIs which many other critical systems use and frequently those APIs do have much more rigorous process in making sure that they are reliable. All of that seems regulated by governments and markets to me. They have promises of reliability and big financial penalties if they were to fail on that reliability.
    - godelski 3y ago
      > But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Because the traditional engineers do this in a lot of stuff and not just high risk domains. You can probably find somewhere an FEA analysis on your TV's legs and where the high stress points are and where it'll break. > They have promises of reliability and big financial penalties if they were to fail on that reliability. Ehhhhh really? Or if everyone does a shit job do we just take it? Most people aren't tech literate. Hell, most apps aren't built by tech literate people. I have a laundry app I have to use and the rooms aren't in any logical order, just randomly placed. Are you tech literate if you don't know a sort function exists? Or if you don't know people like to read things in a sorted order? If you can't google the answer? There's lots of systems that have really shit designs in them and as discussed elsewhere in the thread I don't think companies are having big financial consequences for their lightbulbs not working when the wifi goes down because the people purchasing them aren't aware that such a insane thing would happen. If you're not very tech literate you wouldn't even think that's a possible outcome. So don't just rely on markets because econ 101 isn't enough.
    - syndicatedjelly 3y ago
      > But why are people surprised then that in most software the process is not as thorough as in aerospace or elsewhere with physical things. Outside of engineering, few people have ever even heard the phrase “risk management”, let alone understand the theory behind it. It’s really hard to argue that a developer can consider themself an engineer, when they don’t bother understanding what happens when the thing they “engineered” fails. Yes this applies to web applications too. If someone can’t access an application that gives them directions, it’s possible that they will be stranded. If a healthcare website fails to load a list of available physicians, it’s possible the user gives up and doesn’t seek medical care. The current prevailing attitude in web dev of “who cares” is really a testament to how little most web developers and real engineers have in common. Software engineers working on safety-critical systems deserve that title because they actually have to understand software risks, design appropriate mitigations, and prove their effectiveness.
- godelski 3y ago
  That's actually the entire point. There's consequences to however anything fails. Think the skyscraper example. Do you want to explicitly design a failure mode or do you want to be just "let's see what happens?" Which do you think has a worse consequence? Neither are great, but one is definitely better than the other.