Aerospace Engineering
Reasonable Decisions, Catastrophic System
Nobody set out to build a deadly airplane. Every individual decision in the 737 MAX story had a rationale. That's precisely what makes it so important to understand.
At 6:20 a.m. on October 29, 2018, Lion Air Flight 610 took off from Jakarta. Within seconds of liftoff, the left stick shaker activated, warning the pilots of an aerodynamic stall that wasn't actually happening. Minutes later, a system the pilots had never been told existed began commanding the nose down.
The pilots pulled back. The nose pushed down again. Over the next ten minutes, the cockpit crew countered the automatic nose-down commands roughly 26 times.
The aircraft entered the Java Sea at more than 800 kilometers per hour. All 189 people on board were killed.
Five months later, the same thing happened to Ethiopian Airlines Flight 302. Another 157 people. Same airplane. Same system. Same outcome.
Investigators eventually traced both crashes to a piece of software called MCAS, short for Maneuvering Characteristics Augmentation System. It had been installed quietly, its existence omitted from the pilot manual to avoid triggering expensive retraining requirements. It relied on a single sensor. When that sensor gave a wrong reading, MCAS repeatedly forced the nose down. Pilots who didn't know the system existed had no procedure to fight it.
The temptation is to look for a villain. There isn't one. Or rather, there are too many small ones for that framing to be useful. What the 737 MAX story actually is, when you strip away the headlines, is a masterclass in how complex systems fail: not with a single dramatic mistake, but with a cascade of individually defensible decisions that interact in ways nobody fully anticipated.
Why MCAS Existed at All
To understand MCAS, you have to understand the competitive pressure Boeing was under in 2010 and 2011. Airbus had just launched the A320neo in late 2010, a fuel-efficient update to one of the best-selling narrowbody jets in history. Airlines loved it. Boeing's response was to update the 737 rather than develop a clean-sheet replacement, which would have taken a decade and cost billions.
The upgrade required larger, more fuel-efficient LEAP engines. The problem was the 737's low ground clearance, a design artifact from 1967, when the jet was built to fit into small regional airports.
The new engines had to be mounted further forward and higher on the wing than on the original.
This shifted the aircraft's center of lift. Under certain high-speed, high-angle maneuvers, the nose had a tendency to pitch up more aggressively than pilots expected.
MCAS was the software solution. When sensors detected a high angle of attack (the nose rising steeply), the system would automatically trim the horizontal stabilizer downward, pushing the nose back down. In normal operation, it was invisible. In testing, it worked. The problem was in the assumptions baked into its design.
# MCAS Design Parameters — As Originally Implemented
mcas_original = {
# Trigger conditions
"flaps_up": True,
"aoa_threshold_deg": 14.0, # activate when current AoA exceeds this
"autopilot_engaged": False,
# System behavior
"aoa_sensors_used": 1, # of 2 available, not cross-checked
"stabilizer_step_deg": 2.5, # per activation
"reset_on_release": True, # re-activates after pilot countermeasure
"pilot_notification": None,
"in_pilot_manual": False,
# Original certification scope
"max_deflection_deg": 0.6, # later increased to 2.5° without recertification
}
How Each Decision Made the Next One Worse
The MCAS failure wasn't a single design flaw. It was a series of reasonable-seeming decisions that built on each other, each one shrinking the margin for error a little further. Here is that chain.
Engine placement changes flight dynamics. Larger engines mounted forward and high alter pitch behavior. A software correction is chosen over redesign to preserve type certification and avoid pilot retraining costs.
MCAS authority is quietly expanded. During testing, engineers find MCAS needs to move the stabilizer up to 2.5°, far more than the 0.6° described to regulators. The update is made without recertification. The original approval no longer matches the actual system.
Single-sensor dependency goes unreviewed. MCAS reads angle-of-attack from one of two available sensors. The sensors are not cross-checked. A single faulty reading can trigger the full system. This is treated as an acceptable risk; flight crews, it is assumed, will intervene.
MCAS is omitted from the pilot manual. Including MCAS in training materials would have required airlines to pay for simulator time, threatening the aircraft's price advantage. The system is removed from documentation. Pilots have no knowledge it exists, no procedure for its failure.
Reset logic allows repeated activation. When pilots pull back against MCAS, the system pauses, then reactivates automatically when they release pressure. It can repeat this cycle indefinitely, each time pushing the nose further down than a pilot can counteract through the yoke alone.
A faulty sensor triggers the loop. On Lion Air 610, the left angle-of-attack sensor was damaged on a prior flight and gave a falsely high reading. MCAS activated, pushed the nose down, pilots pulled back, MCAS reactivated. Over the final ten minutes, the crew countered roughly 26 such cycles. Neither crew had any way of knowing what they were fighting.
The pilots didn't have a chance. They were fighting a system they didn't know existed, using reflexes trained against a problem the engineers had already solved. On paper.
— Derived from the KNKT Indonesia and Ethiopian AAIB accident investigation reports
The Swiss Cheese Model, and Why It's Not Enough
Aviation safety has long used a mental model developed by psychologist James Reason: the Swiss Cheese Model. Every safety system has holes: imperfections, failure modes, gaps. Most of the time, the holes don't line up. An accident happens when they do: when a faulty sensor, a missing procedure, an unaware crew, and an inadequate override all fail at exactly the same moment.
In the MAX case, every layer that should have caught the failure had a hole, and all four holes aligned:
- Single-sensor trust. MCAS read from one AoA sensor instead of cross-checking both.
- No MCAS in manual. Pilots had no documentation of the system's existence.
- Infinite reactivation. The reset logic let MCAS re-trigger every time pilots fought back.
- Scope expanded silently. The 2.5° authority increase happened without recertification.
The model is useful, but it can create false comfort. The question is never just "do we have layers?" but "do the layers actually catch each other's failure modes?"
What the 737 MAX case exposed is a subtler failure in how the Swiss Cheese Model gets applied in practice. Organizations often count layers rather than test their interdependencies. "We have redundant sensors" is a layer. "We have pilot training" is a layer. But if the training assumes the sensors are working, those aren't independent layers; they're the same layer, written twice.
True redundancy requires that each safeguard be capable of catching failures that all other safeguards miss. That's a much harder standard. And it's the standard that MCAS never met.
The normalization of deviance. Sociologist Diane Vaughan coined this term after studying the Challenger disaster: the gradual process by which warning signs become normalized because nothing bad has happened yet. Boeing's engineers had repeatedly seen the MCAS authority expanded, the certification scope stretched, the documentation trimmed. Each time, the plane flew fine.
The absence of immediate consequences reads, in the human brain, as evidence of safety. It isn't. It's evidence that the margin for error is shrinking without anyone marking it on a chart.
Four Principles That Survived the Wreckage
The MAX investigation produced thousands of pages of findings. For engineers working on systems far less dramatic than commercial aircraft, four principles distill most cleanly.
Safety-critical systems must be transparent to their operators
A system that acts on a human's behalf, especially one that can override human input, must be fully visible to that human. This applies as much to an automated pipeline managing cloud infrastructure as it does to an autopilot.
The moment you build behavior that operators cannot observe, cannot interrogate, and cannot override with documented procedures, you have created a trap. It may not spring for years. But the trap is set.
Single points of failure in automated systems are architectural defects, not acceptable risks
The MCAS team knew they had one sensor feeding the system. They assessed the probability of sensor failure as low. This is the wrong analysis.
In safety-critical systems, the question is never "how likely is this to fail?" It's "when this fails (and it will fail), what happens?" An architecture that produces a survivable outcome on sensor failure is categorically different from one that produces an unrecoverable one, regardless of failure probability.
Scope changes require full reassessment
MCAS was originally certified to move the stabilizer 0.6°. It was later expanded to 2.5°, more than four times the original, without re-opening certification. Every system has an operating envelope within which its assumptions hold. Expanding behavior outside that envelope without reassessing the assumptions is not an update. It's a new system wearing the old system's approval documents.
Organizational pressure is an engineering input
This last one is the hardest, because it implicates things that feel outside an engineer's control. The omission of MCAS from pilot training wasn't an engineering decision. It was a competitive one, driven by sales commitments and scheduling pressure.
But engineers were in the room when those decisions were made. The discipline of systems engineering exists precisely because technical systems don't fail in isolation from the organizations that build them. Treating organizational pressure as background noise, something engineers just work around, is itself a failure mode.
For 17 months before Lion Air 610 went down, the 737 MAX flew passenger service without incident. Every one of those flights was evidence, to the humans watching, that the system was safe. It wasn't. It was an accident waiting for the right sensor to fail.
The engineering lesson isn't to never trust automation. It's to ask, always: what is this system assuming, and what happens when that assumption is wrong?
