5 ms·

2 planes crashes in less than 5 months. So yes, there was either a system engineering failure, or a completely inept decision in choosing an oversized engine fo

by mtw 8y ago

2 planes crashes in less than 5 months. So yes, there was either a system engineering failure, or a completely inept decision in choosing an oversized engine for an antic airframe. Your choice.

ethbro 8y ago
Or a training requirement failure. Or a UX failure. Or a documentation failure. Or an unrelated failure, given that the RCAs haven't been completed on the crashes. It's amazing the hubris software engineers have in assuming everyone else in an idiot. I am not an expert on aircraft-scale hardware/software codesign projects, aerospace engineering, high-reliability engineering (to aerospace standards), or complex systems analysis. I strongly suspect you, and most of HN, aren't either. Boeing has people with all those skillsets. As does Airbus. As do NTSB and the variety of national certification agencies. So before we toss rocks of certainty around in a comment thread, maybe wait and listen to the experts?
- bobthepanda 8y ago
  Given that at least some of the expert companies involved have attempted coverups of previous failures before, a little bit of skepticism is healthy. https://en.m.wikipedia.org/wiki/Boeing_737_rudder_issues https://en.m.wikipedia.org/wiki/Boeing_737_rudder_issues Authority should not be free from skepticism, even by people who are not authorities.
  - ethbro 8y ago
    We can agree that not all skepticism is valuable skepticism though? I came across this Rand report on the NTSB [1, 1999?]. The conclusions were not good about the funding & staffing levels vs modern accident load. Partly due to more incidents, but moreso due to increased systems complexity per incident. So the NTSB, with a budget of around USD$100M, takes multiple years to deliver a report. And they're a professional worldwide standard on accident investigation. Suffice to say, we're not going to crack this case open on HN. Which isn't to say it isn't productive to debate the relative merits of different regulatory approaches, takeaways for other disciplines, lessons learned, and all manner of things. But let's just have some humility in pretending we're all experts on everything [2]. [1] https://www.rand.org/content/dam/rand/pubs/monograph_reports/MR1122z1/MR1122.1.sum.pdf https://www.rand.org/content/dam/rand/pubs/monograph_reports... [2] Though in fairness, I wouldn't be surprised if there were at least one expert on any given topic here. You folks are awesome.
- onemoresoop 8y ago
  Or test failure?
- mtw 8y ago
  How are those "rocks of certainty"? 2 planes crashed, resulting in deaths of hundreds of people. There is validity in questioning "rocks of certainty". These people were trusted in certifying the plan. These people were trusted in doing the correct choices after the first crash. Obviously, the "experts" did not do what they had to do.
- salawat 8y ago
  There is nothing about a "Software Engineer" which precludes them from achieving a grasp of the finer points of physical engineering disciplines. Finite element analysis, error propagation, systems analysis, statistical process control, mechanics of materials, and all the other equations we've come to rely upon are equally applicable by anyone with the wherewithal to learn to learn them, and are in fact, more likely to be picked up by someone who spends 80% of their time learning "the next tool". In short, while I agree many software engineers may be in possession of an inflated sense of competence, there are many who are legitimate polymaths. This makes appeals of the sort you assert less than useful in the pursuit of substantive conversation.
  - ethbro 8y ago
    Time.
    - salawat 8y ago
      Time is the fire in which we burn, understood. That's why we learn things. So we can predict things, and save time. There's 75 + years in your lifetime. Even auto-didactically you should be able to sift through everything in https://www.engineeringtoolbox.com https://www.engineeringtoolbox.com and use that as the starting point to build up some deep dives into authoritative literature. When you can start to accurately predict outcomes, you're on the right track. You'll know you're in the right neighborhood when you have an increasingly hard time tolerating poor models of reality, and start drifting off thinking about how easy it would be to make that thing if you only had the tools. Happy adventures in the wonderful world of Math! (Don't forget to read the Ethics handbook, and if you want to do it professionally, take the FE, PE, and never forget the iron ring!)
GuB-42 8y ago
If you look at plane crash reports, the disaster is almost always the result of a chain of events. Taken individually, each event is almost insignificant. It's the combination that makes the disaster. In the vase of the Boeing 737 Max the sequence would be something like: - Boeing decided to fit an oversized engine on an older airframe, which can cause a dangerous stall in some unusual configurations. It is not that much of a problem, they just reduced the flight envelope to exclude these configurations. It is not an unusual thing at all. - In order to make sure that dangerous situation is never encountered and to limit training expenses for the pilots, they used software. Then again, not unusual. - In order to avoid writing entirely new software, they extended the functionality of existing software (MCAS). Again, fine. - First problem: the MCAS, now a critical piece of software wasn't properly requalified. - Second problem: The AoA sensor, now critical, isn't properly managed. - Third problem: The pilots weren't properly trained on what to do when MCAS starts crapping out - Fourth problem: The pilots didn't have enough skill to deal with the unexpected situation. - Fifth problem: Maybe some pilots dealt with the problem correctly but the report wasn't properly made and accounted for. Anyone of these steps done right would have averted a disaster. We can't really blame a single one.

by mtw 8y ago

2 planes crashes in less than 5 months. So yes, there was either a system engineering failure, or a completely inept decision in choosing an oversized engine for an antic airframe. Your choice.

ethbro 8y ago

Or a training requirement failure. Or a UX failure. Or a documentation failure. Or an unrelated failure, given that the RCAs haven't been completed on the crashes. It's amazing the hubris software engineers have in assuming everyone else in an idiot. I am not an expert on aircraft-scale hardware/software codesign projects, aerospace engineering, high-reliability engineering (to aerospace standards), or complex systems analysis. I strongly suspect you, and most of HN, aren't either. Boeing has people with all those skillsets. As does Airbus. As do NTSB and the variety of national certification agencies. So before we toss rocks of certainty around in a comment thread, maybe wait and listen to the experts?

bobthepanda 8y ago
Given that at least some of the expert companies involved have attempted coverups of previous failures before, a little bit of skepticism is healthy. https://en.m.wikipedia.org/wiki/Boeing_737_rudder_issues https://en.m.wikipedia.org/wiki/Boeing_737_rudder_issues Authority should not be free from skepticism, even by people who are not authorities.
- ethbro 8y ago
  We can agree that not all skepticism is valuable skepticism though? I came across this Rand report on the NTSB [1, 1999?]. The conclusions were not good about the funding & staffing levels vs modern accident load. Partly due to more incidents, but moreso due to increased systems complexity per incident. So the NTSB, with a budget of around USD$100M, takes multiple years to deliver a report. And they're a professional worldwide standard on accident investigation. Suffice to say, we're not going to crack this case open on HN. Which isn't to say it isn't productive to debate the relative merits of different regulatory approaches, takeaways for other disciplines, lessons learned, and all manner of things. But let's just have some humility in pretending we're all experts on everything [2]. [1] https://www.rand.org/content/dam/rand/pubs/monograph_reports/MR1122z1/MR1122.1.sum.pdf https://www.rand.org/content/dam/rand/pubs/monograph_reports... [2] Though in fairness, I wouldn't be surprised if there were at least one expert on any given topic here. You folks are awesome.
onemoresoop 8y ago
Or test failure?
mtw 8y ago
How are those "rocks of certainty"? 2 planes crashed, resulting in deaths of hundreds of people. There is validity in questioning "rocks of certainty". These people were trusted in certifying the plan. These people were trusted in doing the correct choices after the first crash. Obviously, the "experts" did not do what they had to do.
salawat 8y ago
There is nothing about a "Software Engineer" which precludes them from achieving a grasp of the finer points of physical engineering disciplines. Finite element analysis, error propagation, systems analysis, statistical process control, mechanics of materials, and all the other equations we've come to rely upon are equally applicable by anyone with the wherewithal to learn to learn them, and are in fact, more likely to be picked up by someone who spends 80% of their time learning "the next tool". In short, while I agree many software engineers may be in possession of an inflated sense of competence, there are many who are legitimate polymaths. This makes appeals of the sort you assert less than useful in the pursuit of substantive conversation.
- ethbro 8y ago
  Time.
  - salawat 8y ago
    Time is the fire in which we burn, understood. That's why we learn things. So we can predict things, and save time. There's 75 + years in your lifetime. Even auto-didactically you should be able to sift through everything in https://www.engineeringtoolbox.com https://www.engineeringtoolbox.com and use that as the starting point to build up some deep dives into authoritative literature. When you can start to accurately predict outcomes, you're on the right track. You'll know you're in the right neighborhood when you have an increasingly hard time tolerating poor models of reality, and start drifting off thinking about how easy it would be to make that thing if you only had the tools. Happy adventures in the wonderful world of Math! (Don't forget to read the Ethics handbook, and if you want to do it professionally, take the FE, PE, and never forget the iron ring!)

GuB-42 8y ago

If you look at plane crash reports, the disaster is almost always the result of a chain of events. Taken individually, each event is almost insignificant. It's the combination that makes the disaster. In the vase of the Boeing 737 Max the sequence would be something like: - Boeing decided to fit an oversized engine on an older airframe, which can cause a dangerous stall in some unusual configurations. It is not that much of a problem, they just reduced the flight envelope to exclude these configurations. It is not an unusual thing at all. - In order to make sure that dangerous situation is never encountered and to limit training expenses for the pilots, they used software. Then again, not unusual. - In order to avoid writing entirely new software, they extended the functionality of existing software (MCAS). Again, fine. - First problem: the MCAS, now a critical piece of software wasn't properly requalified. - Second problem: The AoA sensor, now critical, isn't properly managed. - Third problem: The pilots weren't properly trained on what to do when MCAS starts crapping out - Fourth problem: The pilots didn't have enough skill to deal with the unexpected situation. - Fifth problem: Maybe some pilots dealt with the problem correctly but the report wasn't properly made and accounted for. Anyone of these steps done right would have averted a disaster. We can't really blame a single one.