4 ms·

Has software had its materials science moment? The pioneering DeHavilland Comet failed due to unexpected stress fractures. The aviation industry changed marke

Has software had its materials science moment? The pioneering DeHavilland Comet failed due to unexpected stress fractures. The aviation industry changed markedly because of it with years of testing preceding the introduction of any new material or process. Boeing took the lead, DeHavilland never recovered. My cynical view is that little will change in this era.

mrtksn 7y ago
More like MBAs moment maybe? This issue doesn't seem to have anything to do with the difficulties or shortcomings of computer science but product management.
- OldGuyInTheClub 7y ago
  I am no fan of MBAs but in this case I am talking about what I perceive as cultural difference between hardware and software engineering. I come from the experimental/hardware world and I believe there isn't the incremental patch and release mindset for deliverable items. The testing cycles for mission critical hardware is rather brutal. The MBA piece of it is why I'm cynical. "Ho-ho-hold on one second. This installation has a substantial dollar value attached to it." --- C.J. Burke "Aliens"
  - fiter 7y ago
    I think this is a systems engineering problem that may have been due to siloed hardware and software engineering teams. The hardware engineers knew they were making something inherently unstable that the software would have to compensate for. The software engineers believed they had working AoA hardware.
  - joe_the_user 7y ago
    But that isn't the situation, it's really not. The context is airbus has an advanced and fuel-economic model that was eating Boeing market share. Boeing decided to produce one more version of the 737 model - it fit the category and as a fuel-efficinet "drop-in replacement", it was very competitive but was rather aerodynamically unstable. So Boeing added a software system to compensate but didn't tell anyone, didn't make it dependent on redundant sensors and basically produced a plane where, once the facts were all out, it became obvious it could never fly again - not because it could never be made safe but because making safe would involve admitting how flagrantly you initially skirted safety. No one flies on the "once this was utterly unsafe but now we've fixed it" plane if they really have fixed it. Everything about the plane was super advanced but cheap-as-could-be, including the software. But by that token, none of this seems the fault of "software culture", indeed, there's been no implication that the software was at fault in the crashes, just the total shitshow design package, which was indeed the fault of finance and management pushing this approach through.
gethoht 7y ago
MCAS is a band-aid trying to fix the inherent stability of the 737 max. Add in the fact that a single faulty pitch sensor could bring down a plane and blam. Finally, fail to properly train pilots on how the system actually worked and how to override it and here we are today. Software is a part of it but overall I don't see it as a software issue.
- babesh 7y ago
  I think it was a systems issue with the software a part of it. From what I read, the software system is archaic in a bad way since you have duplicate systems but not used for redundancy. Only one set is used at a time and which one is switched with every boot. It had two pitch sensors but each is paired with a single computer. There was an optional add on to use both sensors in some way but this is unreliable as well since you don’t know which is right. It was when the plane was flying with the failed sensor (every other time since only one sensor failed) that they ran into the problem. At least from my readings of how you are supposed to build robust systems from unreliable parts, this is a terrible way to design a system. See https://www.seattletimes.com/business/boeing-aerospace/faa-cautions-airlines-on-maintenance-of-sensors-that-were-key-to-737-max-crashes/ https://www.seattletimes.com/business/boeing-aerospace/faa-c... for info on the sensors. Search for Jim Gray and fault tolerance on how to build reliable systems from unreliable parts. You need redundant parts with voting (which implies more than 2 sensors and more than 2 computers), error detection, etc... Supposedly the Space Shuttle computer systems were designed right although much of the rest of the Shuttle wasn’t designed right. The Boeing way relied on the pilots to compensate for mechanical or software failure. Unfortunately, they seemed to willingly choose to not inform pilots of MCAS and there seemed to be failure scenarios where recovery is difficult. Lastly, I think it is part of the job of a software engineer to push back on requirements and designs that don't work even if it is a failure in the system. Falling back to built as spec'd isn't worth of being called engineering.
jeltz 7y ago
Not really, this was not a software issue. As much as I dislike many current software engineering practices they seem to be 100% innocent here. As far as we know the MCAS behaved exactly according to specifications. All of its flaws seem to be intentional (e.g. only using one AoA sensor, not being easy for the pilots to disable, not being explained to the pilots).

mrtksn 7y ago

More like MBAs moment maybe? This issue doesn't seem to have anything to do with the difficulties or shortcomings of computer science but product management.

OldGuyInTheClub 7y ago
I am no fan of MBAs but in this case I am talking about what I perceive as cultural difference between hardware and software engineering. I come from the experimental/hardware world and I believe there isn't the incremental patch and release mindset for deliverable items. The testing cycles for mission critical hardware is rather brutal. The MBA piece of it is why I'm cynical. "Ho-ho-hold on one second. This installation has a substantial dollar value attached to it." --- C.J. Burke "Aliens"
- fiter 7y ago
  I think this is a systems engineering problem that may have been due to siloed hardware and software engineering teams. The hardware engineers knew they were making something inherently unstable that the software would have to compensate for. The software engineers believed they had working AoA hardware.
- joe_the_user 7y ago
  But that isn't the situation, it's really not. The context is airbus has an advanced and fuel-economic model that was eating Boeing market share. Boeing decided to produce one more version of the 737 model - it fit the category and as a fuel-efficinet "drop-in replacement", it was very competitive but was rather aerodynamically unstable. So Boeing added a software system to compensate but didn't tell anyone, didn't make it dependent on redundant sensors and basically produced a plane where, once the facts were all out, it became obvious it could never fly again - not because it could never be made safe but because making safe would involve admitting how flagrantly you initially skirted safety. No one flies on the "once this was utterly unsafe but now we've fixed it" plane if they really have fixed it. Everything about the plane was super advanced but cheap-as-could-be, including the software. But by that token, none of this seems the fault of "software culture", indeed, there's been no implication that the software was at fault in the crashes, just the total shitshow design package, which was indeed the fault of finance and management pushing this approach through.

gethoht 7y ago

MCAS is a band-aid trying to fix the inherent stability of the 737 max. Add in the fact that a single faulty pitch sensor could bring down a plane and blam. Finally, fail to properly train pilots on how the system actually worked and how to override it and here we are today. Software is a part of it but overall I don't see it as a software issue.

babesh 7y ago
I think it was a systems issue with the software a part of it. From what I read, the software system is archaic in a bad way since you have duplicate systems but not used for redundancy. Only one set is used at a time and which one is switched with every boot. It had two pitch sensors but each is paired with a single computer. There was an optional add on to use both sensors in some way but this is unreliable as well since you don’t know which is right. It was when the plane was flying with the failed sensor (every other time since only one sensor failed) that they ran into the problem. At least from my readings of how you are supposed to build robust systems from unreliable parts, this is a terrible way to design a system. See https://www.seattletimes.com/business/boeing-aerospace/faa-cautions-airlines-on-maintenance-of-sensors-that-were-key-to-737-max-crashes/ https://www.seattletimes.com/business/boeing-aerospace/faa-c... for info on the sensors. Search for Jim Gray and fault tolerance on how to build reliable systems from unreliable parts. You need redundant parts with voting (which implies more than 2 sensors and more than 2 computers), error detection, etc... Supposedly the Space Shuttle computer systems were designed right although much of the rest of the Shuttle wasn’t designed right. The Boeing way relied on the pilots to compensate for mechanical or software failure. Unfortunately, they seemed to willingly choose to not inform pilots of MCAS and there seemed to be failure scenarios where recovery is difficult. Lastly, I think it is part of the job of a software engineer to push back on requirements and designs that don't work even if it is a failure in the system. Falling back to built as spec'd isn't worth of being called engineering.

jeltz 7y ago

Not really, this was not a software issue. As much as I dislike many current software engineering practices they seem to be 100% innocent here. As far as we know the MCAS behaved exactly according to specifications. All of its flaws seem to be intentional (e.g. only using one AoA sensor, not being easy for the pilots to disable, not being explained to the pilots).