Software Engineering Lessons from Aviation

Post by Animats » Thu, May 09, 2019, 7:56 PM UTC

cmurf wrote: post #28

jasode wrote: post #8

Earlier quoted context omitted.

>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 MCA…

>Instead, the MCAS system was poorly designed because of financial pressure to maintain the fiction of a single 737 type rating. OK but how do we know, how is it demonstrated, that this financial pressure condition has now been mitigated? What is the exact nature of the "fix"? And actually what are all of the closed door conversations, back then and now, about the various possible behaviors for this software routine?…

Post by weaksauce » Thu, May 09, 2019, 8:36 PM UTC

Kurtz79 wrote: post #18

jasode wrote: post #12

Earlier quoted context omitted.

>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 outsi…

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 applie…

Post by mcguire » Thu, May 09, 2019, 8:43 PM UTC

maxxxxx wrote: post #10

0x445442 wrote: post #4

Earlier quoted context omitted.

The blog post was good but it was just another variation highlighting the age old conundrum... fast, good and cheap, pick two. Those that value quality are going to be swimming up stream in most organization that develop software because the bean counters always go straight to fast and cheap.

I work in regulated industry and you really don’t want the level of scrutiny regulated processes have in other industries. Innovation would slow down to a crawl or pretty much stop. In a lot of industries you can make trade offs quality vs speed or innovation and be better off by not having perfect quality.

Post by vkou » Thu, May 09, 2019, 9:07 PM UTC

weaksauce wrote: post #43

Kurtz79 wrote: post #18

Earlier quoted context omitted.

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 applie…

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.

Post by qznc » Thu, May 09, 2019, 9:25 PM UTC

HeyLaughingBoy wrote: post #27

qznc wrote: post #24

Earlier quoted context omitted.

There is no other useful meaning of "correct code" apart from "matches specification/design". There is no notion of correctness for design. The design may not be consistent with safety requirements for example.

Of course there is correctness for design! When reviewing a design, the first thing to verify is if it can satisfy its input requirements. In your example, a design that has to satisfy a safety requirement but doesn't is not correct and must be rejected.