On October 29, 2018, 189 people boarded Lion Air Flight 610 in Jakarta. Families. Business travellers. A child. They were in the air for eleven minutes before the plane hit the Java Sea at full speed.
There were no survivors.
Five months later, 157 people boarded Ethiopian Airlines Flight 302 in Addis Ababa. Six minutes after takeoff, the same thing happened.
346 people. Two crashes. One cause. And Boeing knew.
This is not a story about an unforeseeable accident. It is a story about a software decision made under financial pressure, hidden from the pilots who depended on it, and left unfixed after the first crash killed 189 people.
The Business Decision That Started Everything
In 2011, Airbus launched the A320neo — a more fuel-efficient aircraft that airlines immediately wanted. Boeing needed to respond fast or lose billions in contracts.
The answer was the 737 MAX: an update to their most profitable aircraft. But there was a physics problem nobody wanted to talk about.
The new engines were larger. To fit them on the existing airframe, Boeing had to reposition them — forward and higher on the wing. This changed how the plane flew. At certain speeds, the nose pitched up more aggressively than it should. Left uncorrected, this could cause a stall.
Boeing had two options:
- Redesign the airframe. Years of work. Billions of dollars. New pilot certification requirements that airlines would have to pay for.
- Write a software fix. Cheaper. Faster. And — critically — it could be classified as a minor system change, meaning pilots wouldn't need expensive new training.
Boeing chose option 2. They called it MCAS: Maneuvering Characteristics Augmentation System.
The business logic was clear. The engineering consequences were catastrophic.
What MCAS Did — and What It Was Supposed to Do
MCAS monitored the plane's angle of attack (AoA) — the angle between the wing and the oncoming air. If that angle got dangerously high, MCAS would automatically push the nose down to prevent a stall.
The logic:
Sensor detects high AoA → MCAS activates → pushes nose down → pilot stays safe
On paper, reasonable. In practice, three design decisions turned a safety system into a death trap.
The Three Decisions That Killed 346 People
Decision 1: One sensor. No backup.
MCAS read from a single angle of attack sensor. Not two. Not three. One.
Every engineer who has built systems where failure matters knows this is wrong. Redundancy isn't a nice-to-have — it's the foundation of safe system design. If the one sensor fails, the entire system acts on false data with nothing to catch it.
Boeing knew there were two AoA sensors on the plane. They chose not to use both. The Senate investigation later found this decision was driven by the desire to avoid additional certification requirements — requirements that would have delayed the programme and cost money.
In the payment systems I've worked on, even non-critical operations have dual validation. A sensor that controls whether a plane crashes was given less redundancy than a routine financial transaction.
Decision 2: Pilots weren't told MCAS existed.
Boeing classified MCAS as a minor system — too minor to mention in the pilot manual. Pilots flying the 737 MAX were not told the system existed.
This wasn't an oversight. Disclosing a new automated system that could override manual flight controls would have triggered a requirement for full simulator training — at enormous cost to Boeing's airline customers.
So when MCAS activated incorrectly, pilots had no context. They were fighting a system they had never been told about, with no documented procedure for handling it, in a situation that had never been disclosed as possible.
Decision 3: MCAS could override pilots repeatedly — and they couldn't stop it.
When a pilot applied nose-up pressure to counteract MCAS, the system paused — then activated again five seconds later. And again. And again. Each time with full authority.
The pilots were in a tug-of-war against software that never tired, never doubted itself, and had access to controls they didn't know existed. At high speed, the aerodynamic forces eventually became too great to overcome manually.
The Crashes
Lion Air Flight 610 — October 29, 2018
The AoA sensor on the aircraft had been misreading for several previous flights. Maintenance crews had replaced a part but hadn't resolved the underlying fault. The error was noted in the aircraft log. The plane flew anyway.
Within minutes of takeoff, MCAS activated on false data. The crew experienced what felt like a runaway stabilizer — a known emergency with a known procedure. But the procedure didn't work, because the cause wasn't what they thought it was.
For eleven minutes, they fought the controls. At 6:31 AM, the aircraft struck the Java Sea. 189 people died.
Boeing's response: an operational bulletin describing the symptoms — without mentioning MCAS. Airlines and pilots were not told what had actually happened or why.
Ethiopian Airlines Flight 302 — March 10, 2019
Five months later. The Ethiopian Airlines crew had read Boeing's bulletin. They were experienced. When MCAS activated, they followed the prescribed procedure exactly — cutting electric trim and attempting manual control.
But MCAS had already deflected the stabilizer to near maximum. At their speed, the aerodynamic forces made manual recovery impossible. They re-engaged electric trim. MCAS activated again.
Six minutes after takeoff, the aircraft entered a near-vertical dive and crashed into a field 62 kilometres from Addis Ababa. 157 people died.
Boeing knew the first crash had happened. They knew the cause. They did not ground the aircraft.
What the Investigations Found
The U.S. House Committee, the Senate Commerce Committee, and multiple international bodies all investigated. Their conclusions were consistent.
This was not bad luck. It was a predictable outcome of specific decisions:
- MCAS's final behaviour — more powerful than originally designed — was never fully disclosed to the FAA
- Boeing's internal safety analysis classified MCAS as a minor system with low failure probability, based on calculations that later proved incorrect
- The FAA had delegated significant portions of the certification review to Boeing itself — the manufacturer certifying its own safety
- Internal pressure to maintain the programme's schedule and avoid retraining costs overrode engineering concerns that had been raised
The Senate report described a culture where "the pressure for profit and schedule subordinated safety systematically."
Boeing paid $2.5 billion in settlements. No executive faced criminal charges. The families of 346 people received compensation payments.
What This Means for Anyone Who Builds Software
I've spent years building systems where a single error can fail a payment for hundreds of thousands of people. The failure modes in the 737 MAX are not exotic — they're the mistakes engineers make when moving fast under pressure.
Never build a safety-critical system on a single sensor. Redundancy is not optional when failure is catastrophic.
Never hide automated behaviour from the people who depend on it. Hidden complexity doesn't disappear — it becomes a failure mode waiting for the wrong moment.
The cheap fix is sometimes the most expensive decision you'll ever make. Boeing saved money on airframe redesign and pilot training. The cost was $2.5 billion in settlements, the grounding of their most profitable aircraft for 20 months, and 346 lives.
Regulatory capture kills. When the entity being certified controls its own certification, you don't have safety oversight. You have documentation.
Go Deeper
If this story affected you, these are the resources worth your time:
To understand what went wrong:
- "Flying Blind: The 737 MAX Tragedy and the Fall of Boeing" by Peter Robison — the definitive account of the business and engineering failures
- U.S. Senate Commerce Committee Report: "Manufactured Uncertainty" (free, public document)
To build systems that don't fail this way:
- "The Art of Software Testing" by Glenford Myers — the foundation of thinking about failure modes
- "Release It!" by Michael Nygard — how to design systems that fail safely
- Udemy: "Software Testing Masterclass" — practical skills for anyone building critical systems
To understand the broader pattern:
- "Normal Accidents" by Charles Perrow — why complex systems fail, and why it's often inevitable without the right design principles
Next: The Ariane 5 — how reusing 10 lines of code from the wrong rocket destroyed $500 million in 37 seconds.
Sources:
- U.S. House Transportation Committee: Final Committee Report on the Boeing 737 MAX (2020)
- U.S. Senate Commerce Committee: "Manufactured Uncertainty" (2020)
- Ethiopian Aircraft Investigation Bureau: Interim Investigation Report (2019)
- Indonesian NTSC: Final Report, Lion Air Flight 610 (2019)
- IEEE Spectrum: "How the Boeing 737 MAX Disaster Looks to a Software Developer" (2019)
- U.S. Department of Justice: Deferred Prosecution Agreement with Boeing (2021)
- Robison, Peter. Flying Blind: The 737 MAX Tragedy and the Fall of Boeing. Doubleday, 2021.