À propos the previous post, wanted to share a 2019 article by Gregory Travis about the two Boeing 737 Max disasters that shook the world in late 2018 and early 2019. It’s titled How the Boeing 737 Max Disaster Looks to a Software Developer, and I found it fascinating, well-written, and filled with great details.

The Max variant of the 737 was redesigned to allow larger, more efficient engines, but this made it less predictable, which the company decided to paper over in software:

The airframe, the hardware, should get it right the first time and not need a lot of added bells and whistles to fly predictably. This has been an aviation canon from the day the Wright brothers first flew at Kitty Hawk.

Apparently the 737 Max pitched up a bit too much for comfort on power application as well as at already-high angles of attack. It violated that most ancient of aviation canons and probably violated the certification criteria of the U.S. Federal Aviation Administration. But instead of going back to the drawing board and getting the airframe hardware right (more on that below), Boeing relied on something called the “Maneuvering Characteristics Augmentation System,” or MCAS.

Boeing’s solution to its hardware problem was software.

This feels like an interesting extension to the fly-by-wire story of Air France Flight 447, where Boeing seemed to be on the other side of the fence to the Airbus. Perhaps no more:

[…] It seems that with the 737 Max, Boeing has changed philosophies about human/​machine interaction as quietly as they’ve changed their aircraft operating manuals.

Travis argues that people building the software did not fully understand the shift, and particularly didn’t really understand how pilots fly the airplane during more challenging moments:

Those lines of code were no doubt created by people at the direction of managers. Neither such coders nor their managers are as in touch with the particular culture and mores of the aviation world as much as the people who are down on the factory floor, riveting wings on, designing control yokes, and fitting landing gears. Those people have decades of institutional memory about what has worked in the past and what has not worked. Software people do not.

The real reason? Money.

MCAS is certainly much less expensive than extensively modifying the airframe to accommodate the larger engines. […] What’s worse, those changes could be extensive enough to require not only that the FAA recertify the 737 but that Boeing build an entirely new aircraft. Now we’re talking real money, both for the manufacturer as well as the manufacturer’s customers.

That’s because the major selling point of the 737 Max is that it is just a 737, and any pilot who has flown other 737s can fly a 737 Max without expensive training, without recertification, without another type of rating. Airlines—Southwest is a prominent example—tend to go for one “standard” airplane. They want to have one airplane that all their pilots can fly because that makes both pilots and airplanes fungible, maximizing flexibility and minimizing costs.

It all comes down to money, and in this case, MCAS was the way for both Boeing and its customers to keep the money flowing in the right direction. The necessity to insist that the 737 Max was no different in flying characteristics, no different in systems, from any other 737 was the key to the 737 Max’s fleet fungibility. That’s probably also the reason why the documentation about the MCAS system was kept on the down-low.

Put in a change with too much visibility, particularly a change to the aircraft’s operating handbook or to pilot training, and someone—probably a pilot—would have piped up and said, “Hey. This doesn’t look like a 737 anymore.” And then the money would flow the wrong way.

There are some harsh words toward the entire software industry toward the end. This feels directionally accurate to me, and resonated even before the arrival of generative AI:

I believe the relative ease—not to mention the lack of tangible cost—of software updates has created a cultural laziness within the software engineering community. Moreover, because more and more of the hardware that we create is monitored and controlled by software, that cultural laziness is now creeping into hardware engineering—like building airliners. Less thought is now given to getting a design correct and simple up front because it’s so easy to fix what you didn’t get right later.