Twelve minutes into the descent, with the lunar surface rising toward them, a warning tone sounded in the crew’s headsets and a yellow light lit on the guidance display. Buzz Aldrin, the Lunar Module pilot who was watching the computer, read the code aloud — 1202. Neil Armstrong keyed the display and radioed Houston, a touch of urgency in his voice: “Give us a reading on the 1202 program alarm.” On the ground at Mission Control, a guidance officer named Steve Bales had seconds to decide whether the first crewed landing on another world would continue or abort.
He said go.
He could say go because the Apollo Guidance Computer, running software written by a team led by Margaret Hamilton at the MIT Instrumentation Laboratory, had already decided for itself which tasks to keep and which to drop. The 1202 was not a crash. It was the computer announcing, in real time, that it had shed lower-priority work to protect the landing.
The stuck switch
The trigger was a rendezvous radar. During the descent to the Sea of Tranquility, the rendezvous radar — the instrument the Lunar Module would use later to find the Command Module in orbit — had been left in a position that fed the guidance computer a constant stream of data it did not need. The result was that the computer’s processing time was being consumed by a task nobody wanted it doing. As the descent engine throttled and the landing radar streamed altitude data, the computer’s workload crossed a threshold. It ran out of core sets — the small blocks of memory it used to hold in-progress jobs.
That is when it flashed 1202. Then 1201. Then 1202 again. Five alarms in four minutes.
What the code actually did
The AGC had 2,048 words of erasable memory and 36,864 words of fixed core rope memory — less than the working memory of a modern digital thermostat. It ran at roughly one megahertz: a 2.048 MHz crystal clock divided down to a 1.024 MHz internal rate. The team at the MIT Instrumentation Lab, whose Apollo hardware the Smithsonian National Air and Space Museum preserves in its collection, had to fit a real-time flight system inside that envelope.
Hamilton, leading the on-board flight software effort, insisted that the executive program not simply queue tasks first-come, first-served. Instead, every job was assigned a priority. When the computer overloaded, the executive would discard the lowest-priority work in progress, wipe the associated memory, and restart the higher-priority jobs from the last checkpoint. The pilot’s display would blink to signal the reset. The landing would keep going.
That is exactly what happened above the Moon on July 20, 1969. The computer told Armstrong and Aldrin, in effect, that it was busy but coping.
A four-second decision on the ground
Steve Bales did not memorize every possible alarm code. Almost no one could. But during an earlier simulation, a similar overload had appeared and the team had aborted a landing that, in retrospect, should have continued. Jack Garman, a support engineer at Houston, had gone home and written out a handwritten list of alarm codes with a rule for each one: which meant abort, which meant continue.
When the 1202 came through, Garman looked at his list, told Bales the computer was still flying the spacecraft correctly, and Bales relayed the call up to flight director Gene Kranz: “We’re go on that, Flight.” Kranz authorized it, and CAPCOM Charlie Duke passed the word to the crew: “We’re go on that alarm.” Armstrong kept descending.
The tape from the Mission Control loop catches the whole exchange in under fifteen seconds. That is the entire moment on which the landing turned.
Priority scheduling before it had a name
The technique Hamilton’s team used — assigning tasks priorities and having the operating system gracefully drop what it could not finish — is now standard in every real-time system that has to keep working under load. It is what keeps an anti-lock braking system responsive when a sensor floods it with noise, what keeps an airliner’s flight-management computer sane when a data bus goes chatty, and what keeps a modern semiconductor fab line from stalling when a single station falls behind.
In 1969, it did not have the textbook vocabulary it has today. Hamilton has been credited with popularizing the phrase software engineering in part to defend the idea that writing this kind of code was a real engineering discipline, not a clerical task performed by mathematicians who could not get hardware jobs. She has said the term drew laughs at MIT at the time.
Silicon Canals has written before about how the scheduler shed low-priority tasks the moment the processor overloaded, and how the same architectural instinct — build for graceful degradation, not for perfect conditions — reappears every time engineers design a system that has to survive its worst day.
The photograph on the desk
There is a well-known picture of Hamilton standing next to a stack of printouts nearly as tall as she is. The stack is the source code for the Apollo Guidance Computer, all of it, listed line by line on continuous-feed paper. She is smiling. The image has been reproduced widely because the physical volume of the code is the point. The Moon was reached by writing all of that, checking all of that, and simulating all of that, on machines that would today be considered unusable.
The code itself was hand-woven into memory. Core rope memory was manufactured by threading copper wire through or around tiny ferrite cores — through for a one, around for a zero. The programs Hamilton’s team wrote were literally sewn into the hardware. Once launched, they could not be patched.
Why the alarms mattered later
The 1202 story has become a parable inside engineering culture because it captures a design philosophy that is still argued about. Build for the case where everything works, and the system is fast and cheap. Build for the case where something breaks, and the system is slower, more expensive, and occasionally saves a life.
The same principle shows up in how manufacturing systems are built around human factors, where the design assumes that operators, sensors, and supply chains will occasionally fail and that the surrounding system has to absorb the failure without stopping. It shows up in organizational theory too. Writing for Forbes in 2025, Scott Hutcheson described resilience as the ability to absorb change rather than resist it — redundancy, decentralization, continuous adjustment. The AGC’s executive did all three, in software, in 1969.
What the crew saw
From inside the Lunar Module, the alarms would have been terrifying if the crew had not been trained to expect that the computer might complain and still be working. Armstrong later told debriefers he had not spent much time worrying about the alarm once Houston called go, because he was busy looking for a landing spot. The autotargeting had chosen a boulder field. Armstrong took manual control and flew Eagle downrange, past the boulders, to a smoother patch of the Sea of Tranquility.
Eagle touched down with, by most reconstructions, somewhere between 17 and 45 seconds of fuel remaining before an abort call would have been mandatory. The margin was thin. The computer had helped preserve that margin by refusing to fall over.
The line that got copied everywhere
After the mission, Hamilton wrote in an internal memo that the priority-scheduling design had been included specifically because unpredictable inputs from imperfect hardware were a foreseeable class of problem, not a freak event. The design assumption was that the system would be asked to do more than it could, and the question was only what it would do when that happened.
That assumption — plan for overload, not for calm — has since become the default in aerospace, in medical devices, in the flight controllers that keep modern drones stable, and in the industrial control systems that run refineries. It also, quietly, became the standard for how good software everywhere handles a bad day.
The Apollo Guidance Computer’s source code is now on GitHub, transcribed from the original MIT listings. If you scroll through the assembly, you can find the comments the programmers left themselves. One block, in the routine that handled ignition, is labeled BURN_BABY_BURN. Another, near a piece of code the team knew would be treated as a last resort, is labeled TEMPORARY, I HOPE HOPE HOPE.
Fifty-seven years later, that comment is still in the flight software that put humans on the Moon.
