4 ms·

>as software engineers we find a bug and just fix it. [...] Unfortunately, the recent 737 MAX incidents seem to have changed this. I think there's some nuance

by jasode 7y ago

>as software engineers we find a bug and just fix it. [...] Unfortunately, the recent 737 MAX incidents seem to have changed this. I think there's some nuance about MCAS that's lost in all the media reports. As far as I understand, the MCAS software didn't have a "bug" in the sense we programmers typically think of. (E.g. Mars Climate Orbiter's software programmed with incorrect units-of-measure.[0]) Instead, the MCAS system was poorly designed because of financial pressure to maintain the fiction of a single 737 type rating. In other words, the MCAS software actually did what Boeing managers specified it to do: 1) Did the software only read a _1_ AOA sensor with a single-point-of-failure instead of reading _2_ sensors? Yes, because that was what Boeing managers wanted the software to do. It was purposefully designed that way. If the software was changed to reconcile 2 sensors, it would then lead to a new "AOA DISAGREE" indicator[1] which would then raise doubts to the FAA that Boeing could just give pilots a simple iPad training orientation instead of expensive flight-sim training. Essentially, Boeing managers were trying to "hack" the FAA criteria for "single type rating". 2) Did software make adjustments of an aggressive and unsafe 2.5 degrees instead of a more gentle and recoverable 0.6 degrees? Yes, because Boeing designed it that way. Somebody at Boeing specified the software design to be "1 sensor and 2.5 degrees" and apparently, that's what the programmers wrote. I know we can play with semantics of "bug" vs "design" because they overlap but to me this seems to be a clear case of faulty "design". The distinction between design vs bug is important to let us fix the root cause. The 737 MAX MCAS software issue isn't like the Mars Climate Orbiter or Therac-25 software bugs. The lessons from MCO and Therac-25 can't be applied to Boeing's MCAS because that unwanted behavior happens in a layer above the programming: - MCO & Therac: design specifications are correct; software programming was incorrect - Boeing 737MAX MCAS: design specifications incorrect; software programming was "correct" -- insofar as it matched the (flawed) design specifications [0] https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_failure https://en.wikipedia.org/wiki/Mars_Climate_Orbiter#Cause_of_... [1] yellow "AOA Disagree" text at the bottom of display: https://www.ainonline.com/sites/default/files/styles/ain30_fullwidth_large_2x/public/uploads/2019/03/aoa_vaneindicator_aoa_disagree_lg2.jpg?itok=vNHrwopw https://www.ainonline.com/sites/default/files/styles/ain30_f...

Kurtz79 7y ago
"If the software was changed to reconcile 2 sensors, it would then lead to a new "AOA Disagree" indicator which would raise doubts to the FAA that Boeing could just give pilots a simple iPad training orientation instead of expensive flight-sim training." I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. https://blog.ipspace.net/2017/01/never-take-two-chronometers-to-sea.html https://blog.ipspace.net/2017/01/never-take-two-chronometers...
- jasode 7y ago
  >I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. (I can't tell if you're making a side comment or specifically replying to the categorization of "software bug".) Yes, the 737 MAX only has 2 AOA sensors instead of 3 like Airbus A320. This is a physical design of sensors mounted on the airframe. But this aerospace engineering design detail seems outside the scope of assigning blame to software programmers writing code. (There isn't a software coding methodology that makes a 3rd AOA sensor appear.)
  - Kurtz79 7y ago
    It was mostly a side comment, but it seemed appropriate in this context. For such an important system, I would think that a single instance would be too little (single point of failure: even in less mission critical system it wouldn't be allowed), while using two you would not be able to resolve a reading conflict between them (which is the point of the quote), so three is probably a reasonable number. Even if applied to design and not to software programming, the concept is still sound. The point was what the quote meant, not its source.
    - weaksauce 7y ago
      Using two would have been strictly better a design than just one. Obviously three is better but two disagreeing and shutting down mcas would be much, much preferable than relying on one to the grave.

by jasode 7y ago

Kurtz79 7y ago

"If the software was changed to reconcile 2 sensors, it would then lead to a new "AOA Disagree" indicator which would raise doubts to the FAA that Boeing could just give pilots a simple iPad training orientation instead of expensive flight-sim training." I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. https://blog.ipspace.net/2017/01/never-take-two-chronometers-to-sea.html https://blog.ipspace.net/2017/01/never-take-two-chronometers...

jasode 7y ago
>I always liked this quote from the "Mythical Man-Month": “Never go to sea with two chronometers, take one or three”. (I can't tell if you're making a side comment or specifically replying to the categorization of "software bug".) Yes, the 737 MAX only has 2 AOA sensors instead of 3 like Airbus A320. This is a physical design of sensors mounted on the airframe. But this aerospace engineering design detail seems outside the scope of assigning blame to software programmers writing code. (There isn't a software coding methodology that makes a 3rd AOA sensor appear.)
- Kurtz79 7y ago
  It was mostly a side comment, but it seemed appropriate in this context. For such an important system, I would think that a single instance would be too little (single point of failure: even in less mission critical system it wouldn't be allowed), while using two you would not be able to resolve a reading conflict between them (which is the point of the quote), so three is probably a reasonable number. Even if applied to design and not to software programming, the concept is still sound. The point was what the quote meant, not its source.
  - weaksauce 7y ago
    Using two would have been strictly better a design than just one. Obviously three is better but two disagreeing and shutting down mcas would be much, much preferable than relying on one to the grave.