My ten-year-old is obsessed with aviation. Over dinner, he’ll rattle off which airlines fly which wide-bodies out of which hubs, or break down the engine configurations of regional jets I’ve never heard of. I mention this by way of apology: if comparing software to aviation is a cliché, at least in my house I come by it honestly.
One story I keep returning to is the Gimli Glider — because it isn’t just a great flying story. It’s a blueprint for how you build anything that has to be trusted.
On July 23, 1983, an Air Canada Boeing 767 ran out of fuel at 41,000 feet over Red Lake, Ontario. Both engines flamed out. The cockpit screens went dark, and most of the flight instruments died with the generators. Within minutes, one of the most advanced airliners in the world had become a 130-tonne glider carrying sixty-nine people.
And yet it landed safely.
Captain Bob Pearson happened to fly gliders on weekends. First Officer Maurice Quintal remembered an old Royal Canadian Air Force base at Gimli, Manitoba, from his military service. What neither of them knew was that the decommissioned runway had been converted into a community drag strip — and there was a race underway that afternoon. Even so, Pearson side-slipped the powerless jet down onto the asphalt. Nobody died. Ten passengers got minor scrapes on the evacuation slides, and the repaired plane flew for another twenty-five years.
People remember Gimli as a story about two cool-headed pilots. In truth, it’s a story about layers. Every safeguard meant to keep fuel in those tanks had failed — yet behind all of them sat one final layer: a backup ram-air turbine for minimal hydraulics, and a crew trained and drilled to fly a dead stick. Aviation engineers for that kind of resilience on purpose. Software almost never does.
Safety on purpose
Commercial aviation is the safest complex system humans have ever built. It didn’t get there by recruiting smarter people than tech companies do. It got there by assuming that smart, well-rested, well-meaning people will still make mistakes on an ordinary day — and designing the system so a single mistake never brings the plane down.
Software keeps learning this lesson the hard way, one outage at a time, and dismissing the fix as “process overhead.”
The checklist
On October 30, 1935, at Wright Field in Ohio, Boeing test-flew the Model 299, the prototype for the B-17 Flying Fortress. It was the most sophisticated aircraft ever built. It roared down the runway, climbed three hundred feet, stalled, and crashed in flames, killing two people including Boeing’s chief test pilot.
The cause was almost insultingly mundane. Before takeoff, the crew had forgotten to disengage the gust lock — a mechanical pin that keeps the flight controls from buffeting in the wind while parked. Once airborne, the elevators were frozen. Two of the finest aviators in the world were killed by a forgotten latch.
Reporters called the four-engine bomber “too much airplane for one man to fly.” The test pilots who investigated came to a sharper conclusion: it wasn’t too much airplane to fly; it was too much airplane to remember. They didn’t need braver pilots. They needed an index card. Armed with a simple pre-flight checklist, crews flew the next 1.8 million miles without a single accident.
Engineers often bristle at checklists. On a good day, a checklist feels patronizing — a script forcing you to verify things you already know by heart. But a checklist isn’t written for your best day. It’s written for the one when you’re tired, running behind, and paged in the middle of dinner — the exact moment your brain skips step nine while remaining 100 per cent convinced you did it.
Software has its own checklists: runbooks, pre-deploy checks, migration playbooks, incident templates. Yet engineering culture routinely treats them as red tape for people who aren’t sharp enough to hold the system in their heads. That gets human nature completely backwards. Checklists exist because experts forget — and they forget fastest when the pressure is highest. The routine feels tedious on every day except the one when it saves you, and you never get advance notice of which day that will be.
When the holes line up
Aviation also popularized the clearest mental model of failure we have: psychologist James Reason’s “Swiss cheese” model. Picture a system’s defenses as a stack of Swiss cheese slices. No layer is solid; every slice has holes. Usually, a hazard that slips through a hole in the first slice hits solid cheese in the second. Catastrophe only happens when the holes in every single slice happen to line up at once.
The Gimli Glider was a textbook alignment of holes. The 767’s electronic fuel processor had failed, forcing the ground crew to measure fuel manually with a drip stick. Because Canada was mid-transition to the metric system, this new 767 measured fuel in kilograms — but the crew multiplied the volume by 1.77 (pounds per litre) instead of 0.8 (kilograms per litre). Both the mechanics and the pilots checked the math, and because the conversion was brand new to everyone, nobody’s gut flagged that the tanks were less than half full. Close any single hole in that stack and Flight 143 is an unremarkable trip to Edmonton. It took all of them lining up to starve both engines at 41,000 feet.
Software outages unfold the exact same way. We love writing “Root cause: null pointer in billing service” because we crave a single culprit. In reality, an outage is almost never one thing. It’s the bug, plus the staging test that was skipped, plus the alert someone muted three weeks ago, plus the outdated runbook, plus the only engineer who knew the legacy code leaving in March. A serious post-mortem doesn’t hunt for a scapegoat; it maps the holes in the cheese and closes them.
That’s why aviation treats incident investigation as blameless. When it takes five aligned holes to cause a crash, firing the person who happened to be holding the fifth slice fixes nothing — and gets rid of the one person who will never make that mistake again.
Where the comparison breaks
Of course, the lazy version of this argument is “software should just act like aviation” — and that ignores how different the two worlds are.
Aviation safety isn’t just a mindset; it’s backed by statutory machinery that software doesn’t have. National safety boards have subpoena power. Near-miss reporting is mandatory and legally protected. A regulator can ground a global fleet overnight, and airframe designs evolve over decades. Software ships several times a day, with no inspector standing on the tarmac.
Much of that gap is healthy. A crashed web app doesn’t kill two hundred people. Process should scale with the stakes: a hospital clinical system or a core banking ledger demands a level of rigor that would suffocate a three-person startup.
The part that’s free
Still, look at what aviation’s two best habits actually cost. A checklist costs thirty seconds of confirming what you already know. The Swiss cheese mindset costs you the satisfaction of blaming a single villain. Neither requires an act of Parliament or the authority to ground a fleet. They are simply a posture — a choice you can make before anything breaks.
That choice comes down to humility: recognizing that your own expertise is the layer most likely to fail under pressure, and building the quiet backup layer anyway — even if you resent maintaining it on the ninety-nine days nothing goes wrong.
The crew of Flight 143 didn’t land safely on a Manitoba drag strip because they were superhuman. They walked away because generations of engineers before them decided that “we’ll be careful” wasn’t an architecture — and kept adding backup layers until the afternoon every primary system failed and the last layer held. Building software for high stakes is the exact same bet.