Ethiopian Airlines Boeing 737 pilots 'could not stop nosedive'

I really didn't want to flame the room. As a commercially-rated small plane pilot and coder, I have a passion here and it both hurts me and makes me really angry.

I said this was a programmers problem, not a software problem, and I identified one of the key causes as programmers being isolated from user outcomes. Probably not a big deal if your user can't get to the website for 10 minutes. Different thing entirely here.

So this is a complexity * project organization problem. Yep, I think there's regulatory capture, and it may or may not have added to the problem. But you could repeat the factors I've listed in any country or industry you like and get the same results. So this isn't a "Boeing has corrupted the FAA" thing. Sure, it might have, and that's a good thing to talk about. But that's not it.

In fact, if you look at it that way, you're just continuing to silo off responsibility. This is another way of saying "Let's create yet another component that has oversight of all these other components that interact in ways we can't predict so that it can be the arbiter of what's safe or not" That's not a bad idea per se. It becomes bad because "the arbiter of what's safe or not" can mean all kinds of freaking things, many of which may be inconsistent or missing.

So really it just makes it worse. Let's say you make changes A, B, and C. Then it happens again with other systems. We come back in five years with another crash and sure enough, we've got the same clusterfuck as everybody points at one another saying that they've done their job but the other guy screwed up. Is it possible to black box test extremely complex systems? A lot of engineers have pretended that for a long time that you could. We are reaching the limit of how politically plausible that is.

I don't have an easy answer to the question "What do we do right now as programmers?" but I know that programmers, as a group of people, are in a unique spot to understand this problem and try to get attention for it.

A lot of us have worked on subsystems that eventually got used in ways we might find horrible and immoral. In that case you make a judgment call on whether the overall good beats the damage you may cause. In this case, however, these components and systems were built and integrated for no other purpose than this particular airplane. And bad things are happening. Joe Programmer can't be responsible for fixing Boeing, but he sure as hell can be responsible for having Boeing and other entities that build complex systems understand the horrible results of what they're doing and why.

ADD: Look at the comments here. It's a software thing. It's a hardware thing. Yesterday it was a training thing. A few days ago it was a distracted crew. Now we're talking about regulatory capture. Systemic problems are problems such that each piece can work in good faith and do a good job -- yet the overall results of the system gets worse and worse. A good sign of a systemic problem is when intelligent, well-meaning people end up pointing fingers all over the place. This is not a programming problem because it's in the program. It's a programming problem because we're in a spot to understand what got us here -- and I believe we have a moral responsibility to help others understand. A second sign is when new components are suggested as answers to problems the existing components are manifesting.

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".

Every time I read about these plane accidents, I wonder why planes don't have any emergency features to save these people. Couldn't you build a plane that would eject the cabin as a parachute module or something. Yes, I'm sure this is naive, but why?

Edit: My point is that almost anything is better than crashing down with the plane.

The 737 is still mostly 1960s technology, despite all the tweaks over the years. With autopilot off, autothrottle off, and electric trim disabled, which is the situation the Ethopian pilots would have ended up in from following the checklists, all the main flight controls are entirely manual. Only the engine FADECs can't be turned off, and you wouldn't want to because modern engines rely on computised controls.

Excuse me, no.

This incident was decidedly not their fault.

The blame lies 100% with Boing.

This event doesn’t not count toward their safety rating.