4 ms·

I am pretty sure the software here did exactly what it was supposed to do. There was no buffer overrun, no NullPointerException, not any other kind of bug. Ther

I am pretty sure the software here did exactly what it was supposed to do. There was no buffer overrun, no NullPointerException, not any other kind of bug. There was just software that reacted exactly as specified. The problem is: those specifications were bad. It's a bad idea to just rely on one single sensor when you actually have two, it's a bad idea to write software that disengages on manual input counteracting its decisions, then resume overriding pilot decisions out of the blue with a delay of a few seconds again. And it's an absurdly bad idea to do all of this while not telling the humans that will have to operate the machinery in the end ANYTHING about how all of this works. I totally get why Boeing thought all of those obviously bad ideas were "good" - because they helped their bottom line. It wouldn't be possible to completely hide the existence of the MCAS if there was a potential for a sensor disagreement that has to be solved manually by pilots, and if it hadn't been possible to completely hide the existence of MCAS, it wouldn't have been possible to get the new plane out on the market without requiring expensive re-training. And that would have made a very convenient marketing claim of Boeing impossible to make: "this new plane can be flown by all those pilots familiar with the old plane, no re-training necessary, just read these few pages on an iPad and you're good!". But this clearly makes this disaster not a "programmers killing people" incident. If any "xxx killing people" classification is to be made here, it's "managers killing people".

kharms 8y ago
Bad programming was not the sole or root cause but it was a cause, and people died. You can't punt on that unless you want software engineer to actually mean code monkey. The same way a building architect has to sign off on the design demands of a a client, a software engineer on safety-critical systems must evaluate the spec and consider the effects of edge cases.
- peteradio 8y ago
  What do you suppose the spec was here and how did the Engineer neglect to fulfill it? These specs are very compartmentalized, you think the Engineer is responsible for the big picture understanding and gets to take it up with the VP? No.
  - delfinom 8y ago
    Yea, at a company like Boeing. They compartmentalize the fuck out of the engineering perhaps a bit too far.
- quickthrower2 8y ago
  While a SW engineer isn’t a code monkey, they are probably the last line in a chain that started with someone saying let’s bolt some oversized engines on this plane, and really even if there is a SWE who spotted the problem and pushed back, the only way to effectively make this software safe is to not need it, I.e design a new plane, and the only way to make that happen is to blow the whistle. So yeah a SWE could have done this but so could anyone involved earlier in the chain.
jeltz 8y ago
I do not think all blame should be removed from the programmers that easily. Programmers should think about the ramification of their code and not just blindly implement bad specifications which will get people killed. Now it is possible that Boeing is such a toxic place that any disagreement is silenced, but I do not think we should automatically give the programmers a pass just because it is a specification issue.
- quickthrower2 8y ago
  The question is who is going to blow the whistle because that is what it comes down to. It’s just not a simple case of doing a better job. It’s going to need someone prepared to lose their job. If it was a simple case of “hey boss I think something is wrong here” and they listened and acted I think that would have happened. Something must be culturally wrong I am guessing.

kharms 8y ago

Bad programming was not the sole or root cause but it was a cause, and people died. You can't punt on that unless you want software engineer to actually mean code monkey. The same way a building architect has to sign off on the design demands of a a client, a software engineer on safety-critical systems must evaluate the spec and consider the effects of edge cases.

peteradio 8y ago
What do you suppose the spec was here and how did the Engineer neglect to fulfill it? These specs are very compartmentalized, you think the Engineer is responsible for the big picture understanding and gets to take it up with the VP? No.
- delfinom 8y ago
  Yea, at a company like Boeing. They compartmentalize the fuck out of the engineering perhaps a bit too far.
quickthrower2 8y ago
While a SW engineer isn’t a code monkey, they are probably the last line in a chain that started with someone saying let’s bolt some oversized engines on this plane, and really even if there is a SWE who spotted the problem and pushed back, the only way to effectively make this software safe is to not need it, I.e design a new plane, and the only way to make that happen is to blow the whistle. So yeah a SWE could have done this but so could anyone involved earlier in the chain.

jeltz 8y ago

I do not think all blame should be removed from the programmers that easily. Programmers should think about the ramification of their code and not just blindly implement bad specifications which will get people killed. Now it is possible that Boeing is such a toxic place that any disagreement is silenced, but I do not think we should automatically give the programmers a pass just because it is a specification issue.

quickthrower2 8y ago
The question is who is going to blow the whistle because that is what it comes down to. It’s just not a simple case of doing a better job. It’s going to need someone prepared to lose their job. If it was a simple case of “hey boss I think something is wrong here” and they listened and acted I think that would have happened. Something must be culturally wrong I am guessing.