Last time, we promised you the story of how aviation’s software standards came to be. But every rulebook is written in response to something — and before there could be rules for software in the sky, software had to get there first.
So this is the story before the story: how a computer built to reach the Moon ended up flying an airplane over the California desert, and why that flight changed what it means to be safe in the air.
It’s a story with fresh resonance right now. Rockets that land themselves upright on ocean barges. Capsules carrying astronauts while millions watch live. A new generation looking up at the sky the way their grandparents did in 1969. Every bit of that modern spectacle flies on software — and the question of whether software could be trusted with flight was asked, and answered, half a century ago, by people improvising with a Moon computer and a borrowed fighter jet.
Before Software: Machines That Could Almost Think
Pilots have had mechanical help for over a century. As early as 1914, a young engineer named Lawrence Sperry stunned a Paris crowd by flying past the grandstand with his hands raised off the controls — his gyroscopic “autopilot” holding the aircraft steady. For the next several decades, that kind of help was mechanical and analog: gyroscopes, linkages, electrical circuits. Clever machines, but machines that did exactly one thing.
A computer is different. A computer follows instructions — and instructions can be changed, combined, and layered into behavior of almost unlimited complexity. That power is exactly what makes software so useful, and exactly what would eventually make proving its safety so hard.
The first place that power was truly trusted with human lives wasn’t an airplane at all.
The Computer That Went to the Moon
To land astronauts on the Moon, NASA needed navigation and control no human could perform by hand. The answer was the Apollo Guidance Computer, designed at MIT’s Instrumentation Laboratory, with onboard flight software developed by a team led by a young engineer named Margaret Hamilton — who would later be awarded the Presidential Medal of Freedom for that work.
The machine itself sounds almost comical today. It had roughly 38 kilobytes of memory — thousands of times less than a single photo on your phone. Much of its software was physically woven into the hardware: copper wires threaded by hand through tiny magnetic cores, one bit at a time, by skilled workers — many of them women — at a Massachusetts factory. A bug couldn’t be patched with a download. The program had to be right before it was woven.
And then, during the most famous landing in history, the software proved exactly why it deserved trust. As Apollo 11 descended toward the Moon, the computer began throwing alarms — it was being flooded with more work than it could handle. But Hamilton’s team had designed the software to recognize overload, shed its least important tasks, and keep doing the critical ones: flying the spacecraft. The landing continued. The software had not just worked; it had failed gracefully, exactly as designed.
Remember that phrase. Decades later, designing for graceful failure would sit at the heart of every aviation software standard.
“I Just Went to the Moon With One”
After Apollo 11, Neil Armstrong took a desk job — head of aeronautics research at NASA. And he brought an idea with him: if a digital computer could be trusted to land on the Moon, it could be trusted to fly an airplane.
This was a radical proposition. Aircraft control systems were mechanical — rods, cables, and hydraulics physically connecting the pilot’s hands to the control surfaces. Replacing all of that with a computer and electrical wires (a concept called “fly-by-wire”) meant asking pilots to bet their lives on code. When engineers and pilots hesitated, Armstrong’s reply was hard to argue with: he had just been to the Moon with one.
NASA approved the project, and engineers at the Flight Research Center in California took a Navy F-8 Crusader fighter jet, removed its mechanical control system entirely, and installed an Apollo spacecraft computer in its place — literally the same kind of machine that had flown to the Moon, repurposed to fly an airplane.
May 25, 1972
On that morning, NASA research pilot Gary Krier took off from Edwards, California, in the first aircraft ever controlled by a digital computer — with no mechanical backup. If the software failed, there was only an analog emergency system between him and the desert floor.
It was never needed. Not on that flight, and not once across the program’s 210 flights over the next 13 years. The F-8 program did more than prove a concept; it carefully documented what worked and what didn’t — which design techniques produced trustworthy systems, how a computer could tolerate real faults and keep flying. It was, in a sense, aviation’s first body of evidence about software safety, gathered years before anyone wrote a standard requiring it.
Software Spreads Its Wings
Through the late 1970s and early 1980s, digital systems moved from research aircraft into the airliners you and your family actually fly. Flight management computers began handling navigation and fuel planning. Electronic “glass cockpit” displays began replacing walls of mechanical gauges. In 1988, the first airliner flown entirely by digital fly-by-wire entered service, and in 1994 a second major airliner family followed. Today, essentially every modern transport aircraft trusts software with functions that once belonged to cables and hydraulics.
Each step brought real benefits — smoother flights, better fuel efficiency, fewer opportunities for certain kinds of human error. But notice what else was happening: with each step, software was taking on responsibilities where failure was less and less acceptable. A navigation hiccup is an inconvenience. A flight-control failure is not.
The Question That Demanded an Answer
By the early 1980s, aviation faced a problem unlike any in its history. The industry knew how to prove a wing was strong — you could x-ray the metal, tug the cables, count the rivets, and ultimately bend a test wing until it broke. But you can’t x-ray a line of code. You can’t tug on a function to see if it holds. Software doesn’t wear out, corrode, or fatigue — when it fails, it fails because of a flaw that was always there, woven in from the beginning, waiting for the one situation nobody thought to test.
Software had proven it could fly. Now the question became urgent: how do you prove it’s safe enough to fly — every flight, for everyone?
Answering that question would take the better part of a decade, draw in engineers from across the entire industry, and produce one of the most quietly successful rulebooks ever written.
That’s where we’ll pick up next time.
At AeroCert Institute, we believe everyone — passengers, students exploring aerospace careers, and small businesses bringing new ideas to the skies — deserves to understand the systems that keep flight safe. Every article we publish is free, with no paywalls and no memberships, and always will be. If you learned something today that you never knew before, that’s exactly the gap we exist to close. Help us reach more people like you — consider supporting our work with a donation.
Leave a Reply