Margaret Hamilton, who led the MIT team that wrote the onboard flight software for the Apollo spacecraft, died on September 30. She was 90.
Most obituaries will reach for the same scene: On July 20, 1969, with the lunar module Eagle still roughly six miles above the Moon, the guidance computer flashed a code nobody in the cockpit had memorized: 1202. Then 1201. Then 1202 again. Neil Armstrong asked Houston what it meant. Houston, after a few very long seconds, said to keep going.
The computer kept flying the descent because it had been built to fail in a particular, orderly way. That was Hamilton’s real subject for six decades. Not the Moon, exactly. The question of what a machine should do when the world hands it something nobody planned for.
That sounds abstract. Her work never was.
Weather, then radar
Margaret Elaine Heafield was born on August 17, 1936, in Paoli, Indiana. She studied mathematics at the University of Michigan, transferred to Earlham College, and graduated in 1958 with a mathematics degree and a minor in philosophy. Her plan was abstract mathematics and, eventually, a professorship.
The plan bent in 1959. She had moved to Boston with her first husband, James Cox Hamilton, while he studied law, and took what was supposed to be a temporary job in MIT’s meteorology department. Her boss was Edward Lorenz. Her machine was an LGP-30, a desk-sized computer with a rotating magnetic drum for memory, later supplemented by time on a PDP-1.
She wrote weather-prediction code. Lorenz was, in those years, noticing that tiny differences in starting conditions produced wildly divergent forecasts, the observation that became chaos theory. He later credited her programming in his published work. When she moved on in 1961, she trained Ellen Fetter to take over the job.
Next came MIT Lincoln Laboratory and SAGE, the Semi-Automatic Ground Environment, America’s continental air-defense network. Hamilton wrote software for the XD-1, the prototype of the AN/FSQ-7, a vacuum-tube giant built to spot hostile aircraft. New programmers there were traditionally handed one notorious program that nobody had ever gotten to run. Its author had written the comments in Greek and Latin. Hamilton got it working.
The more lasting thing she took from SAGE was a preoccupation. A program watching for bombers cannot crash, hang, or quietly produce a wrong answer. Software reliability was barely a phrase in 1962. For her it became the job.
A newspaper ad and a very small computer
In 1965 Hamilton was about to start graduate school when her husband spotted a newspaper ad. MIT’s Instrumentation Laboratory, which held NASA’s contract for Apollo guidance and navigation, wanted people to write software to send a man to the Moon. She applied. She became the first programmer hired for Apollo at MIT, and the first woman programmer on the project.
The hardware she was writing for deserves a moment, because it explains nearly everything that follows. The Apollo Guidance Computer had about 2,048 words of erasable memory and 36,864 words of fixed memory. The fixed memory was core rope: copper wire threaded by hand through or around magnetic cores, a 1 or a 0 depending on the path. Once a program was woven, changing it meant weaving it again. Bugs were not patched. They were manufactured.
She started on the uncrewed flights and moved up quickly. By 1968 she was assistant director in charge of the Command and Service Module software, and Apollo’s software effort had grown to more than 400 people. She later directed the lab’s Software Engineering Division, with responsibility reaching into the Lunar Module code and, afterward, Skylab.
She was in her late twenties and early thirties for all of this. So were many of the people around her. Management, she later said, mostly left them alone, because nobody above them really understood what software was.
The Lauren error
Hamilton sometimes brought her daughter, Lauren, to the lab on evenings and weekends. One day the four-year-old was playing at the command module simulator and pressed her way into P01, a prelaunch program, while the simulated spacecraft was in midflight. The simulator crashed.
A child had found a sequence of keystrokes that the system accepted and could not survive. Hamilton’s reaction is the instructive part. She did not conclude that children should stay out of simulators. She concluded that the software trusted its operator too much.
She proposed a code change to block P01 during flight. NASA turned it down on the reasonable-sounding grounds that astronauts were too well trained to make that error. So the protection went into the documentation as a warning instead: do not select P01 during flight.
In December 1968, on Apollo 8, the first crewed flight around the Moon, Jim Lovell selected P01 during flight. The program did what P01 does. It reinitialized, and the navigation data the spacecraft had been carefully accumulating was overwritten. The MIT team spent hours working out how to rebuild the state from the ground and uplink corrected data. Afterward, the fix Hamilton had asked for went in.
Today this falls under the label of defensive programming: treat every input as possibly wrong, including the ones from experts. The lesson she drew was sharper. The question is never whether a well-trained human will make a given mistake. Over enough hours and enough people, someone will. The question is what the system does next.
Six miles up
The 1202 alarm is usually told as a story about nerve. It is better understood as a story about scheduling.
The Apollo computer did not run one program from top to bottom. It ran an executive, a small operating system that juggled many jobs at once, each with an assigned priority. The asynchronous design came from J. Halcombe Laning at the lab; Hamilton’s team built the flight software on top of it, along with the error detection, restart logic and alarm displays that surrounded it. Each job needed a slot in a tiny fixed pool of memory areas. When jobs piled up faster than they finished, the pool ran dry.
That is what happened during the descent. The rendezvous radar, which had no role in landing, was electrically configured in a way that sent a stream of spurious signals to the computer. Exactly why the switch sat where it did is still argued over by people who were there. The effect is not in dispute: the computer spent a meaningful share of its time servicing those signals, so routine work queued up. The executive ran out of slots. 1202 meant no free core sets. 1201 meant no free vector work areas.
A naive design would have thrown away the last job, or locked up, or kept going with corrupted state. This one restarted in a controlled way. The software kept tables of which jobs were essential and where each could safely resume. On restart, it rebuilt those jobs from known-good checkpoints and dropped the rest. Guidance, throttle and attitude control survived. Lower-priority work, such as some of the display updates Buzz Aldrin had requested, did not.
Hamilton put it plainly in a 1971 letter to Datamation. The computer, she wrote, was in effect telling the crew “I’m going to keep only the more important tasks.” The restarts took a fraction of a second, so to the crew the descent simply continued, punctuated by alarms.
The alarms themselves were part of the design. Her priority displays could break into whatever the astronauts were looking at and put an emergency in front of them, with a go or no-go decision attached. She had even thought about the lag between the display changing and the program behind it switching over. Her guidance to crews: when a priority display appears, count to five before pressing anything.
In Houston, guidance officer Steve Bales and computer specialist Jack Garman had seen these codes in simulation and knew the landing software was still running underneath them. The call came back as a go. Eagle landed with the alarms behind it.
The name, and the argument behind it
During Apollo, Hamilton began calling what her team did “software engineering.” Colleagues found it funny. Hardware was engineering: it had tolerances, test rigs, failure analysis. Software was what you loaded onto the hardware afterward.
She meant the phrase as a claim about status, and about method. If code could put three people in danger, it deserved the same discipline as a pressure vessel or a circuit board: specifications, reviews, end-to-end testing, a theory of how it fails. She told the story of the meeting where a respected hardware engineer finally agreed with her in front of the room. What mattered to her was not that he liked the word. It was that the software people had earned a seat.
She was not the only person reaching for the term in those years. A 1968 NATO conference in Garmisch put “software engineering” in its title, and historians still trade footnotes about first use. That debate somewhat misses her contribution. The term spread because practitioners like Hamilton showed, under the hardest possible conditions, that the thing it named could be done.
Preventing errors instead of finding them
After Apollo, Hamilton went back through the program’s error reports and sorted them. A large share, she found, were not logic mistakes inside a module. They were interface errors: two correct pieces disagreeing about data, timing, or who controls what. Testing catches these late and expensively. She wanted a way to make them impossible to write in the first place.
In 1976 she co-founded Higher Order Software in Cambridge with Saydean Zeldin, building on a methodology the two had developed at MIT. Its product, USE.IT, was used in government programs, including an Air Force effort to formalize and automate the IDEF modeling language. The underlying ideas found their way into academic work too; David Harel built a proposal for structured programming on them in 1980.
She left HOS in 1985 and founded Hamilton Technologies in March 1986. Its center was the Universal Systems Language and the 001 Tool Suite, built on an approach she called “development before the fact.” The premise: define a system in a formal language whose structure enforces correct relationships between parts, then generate the implementation from that definition. Fewer errors are found because fewer are introduced.
This line of work never became as familiar as the Apollo story. It is, though, the thread that ties her career together. SAGE taught her that software must not fail. Apollo taught her how it fails. The companies were her attempt to design the failures out.
The photograph
In 1969, at MIT, someone photographed Hamilton standing beside a stack of bound program listings roughly as tall as she was. The stack held the printouts of the onboard flight software for the Lunar Module and Command Module teams she led. For decades it was an archive photo. Then, around the 2010s, it started circulating online, and a generation of programmers who had never heard her name saw it.
The image does a lot of work in very little space. It makes software physical, which it almost never is. It shows a woman at the center of the most celebrated engineering project of the century, at a time when most accounts left women out. And it quietly corrects the idea that Apollo was a triumph of rockets alone.
The recognition that followed was substantial:
- 2003: NASA’s Exceptional Space Act Award. Its $37,200 cash prize was the largest NASA had given an individual.
- 2015: The Apollo 11 guidance code was posted to GitHub, where people still read it, annotate it, and leave jokes in the issues.
- 2016: The Presidential Medal of Freedom, presented by Barack Obama on November 22.
- 2017: Computer History Museum Fellow; the same year, LEGO’s Women of NASA set, designed by MIT’s Maia Weinstock, put a minifigure of Hamilton beside a tiny stack of code.
- 2022: Induction into the National Aviation Hall of Fame.
Over her career she published more than 130 papers, proceedings and reports.
She is survived by her daughter, Lauren Hamilton, and son-in-law Richard Selesnick; two grandsons; four great-grandchildren; and her siblings John, David and Kathryn. A memorial service is planned for the spring in Cambridge, Massachusetts.
What the alarm was for
It is tempting to file Hamilton under heroism: the brilliant programmer whose code saved the landing. She resisted that framing in her own way, by talking about restarts, priorities and interface errors instead of herself. The Apollo 11 software did not succeed because it was flawless. The spacecraft around it carried an interface problem nobody had caught in testing. It succeeded because it assumed something would go wrong and had already decided what to keep.
That is the habit worth taking from her, and it applies well beyond spacecraft. When you design anything people depend on, write down what it should sacrifice first under load, and what it must never drop. Then assume the four-year-old, or the astronaut, will find the button you were sure nobody would press.
Sources
- Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90 (MIT News, October 7, 2026)
- Margaret Hamilton (software engineer) (Wikipedia)