3 ms·

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 exper

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.

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.