Margaret Hamilton: The Architect of Apollo

When Margaret Hamilton began working with computers in the late 1950s, programming had no university degree, no professional body and little respect. Programmers were often treated as clerks who translated an engineer's ideas into code. Hamilton spent two decades arguing that the work deserved the standing of an engineering discipline. Her team's software flew the Apollo missions, and the way she and her colleagues thought about errors still shapes how people build reliable systems.

From mathematics to machines

Hamilton was born in 1936 in Paoli, Indiana, and studied mathematics at Earlham College, graduating in 1958. She planned to teach and to continue to graduate study in abstract mathematics. She took a job at the Massachusetts Institute of Technology to support her husband's studies at Harvard, and she expected the job to be temporary.

At MIT she worked for the meteorologist Edward Lorenz, who studied the mathematics of weather. Lorenz is remembered for showing that tiny differences at the start of a forecast can grow into very different results later, an idea popularly called chaos theory. Hamilton wrote programs for his models on early computers, including the LGP-30. She learned the craft the way most programmers of the time did, by trying things, reading manuals and debugging.

The programs were hard to get right. A weather simulation ran for hours, and one wrong instruction could spoil the whole run. Hamilton developed a habit that would define her career. She asked what could go wrong, and she designed the program so that wrong things were caught early.

SAGE: software for an air defense network

From MIT, Hamilton moved to Lincoln Laboratory, where she worked on SAGE, the Semi-Automatic Ground Environment. SAGE was a network of radar stations and computers built in the 1950s to help the United States Air Force track aircraft that might attack North America. The central machine at each site was the AN/FSQ-7, a computer that filled a large two-story building and used tens of thousands of vacuum tubes.

SAGE was among the largest software projects of its era. It joined radar data, computer calculation and human operators into one system. Operators sat at consoles, looked at a display of tracks and pointed at targets with a light gun. Programmers wrote code that ran continuously, took input from many sources and could not simply stop when something went wrong.

Hamilton later described the work as formative. She learned how to build software in which many parts must work together in real time, and she saw how large systems can fail in ways that nobody planned for. Her time on SAGE gave her a feel for the problem that Apollo would present again on a smaller scale.

Joining the Moon program

In 1963 Hamilton joined the MIT Instrumentation Laboratory, later renamed the Charles Stark Draper Laboratory. NASA had chosen the laboratory to design the guidance and navigation system for the Apollo spacecraft, and the laboratory needed programmers. Hamilton started on an early project and then moved into the flight software for the Apollo Guidance Computer. Over the following years she became head of the software engineering division, which grew to include many programmers.

The computer she wrote for was extremely limited by modern standards. The Apollo Guidance Computer had about 36,000 words of fixed memory and about 2,000 words of erasable memory. Each word held 15 bits of data plus a parity bit. A programmer had to fit all of the flight software into this space, and the software had to cover navigation, steering, engine control and the interface with the astronauts.

The fixed memory was a technological marvel. It was called core rope memory. Technicians threaded fine wires through or around tiny magnetic cores. A wire that passed through a core stood for a one, and a wire that passed around it stood for a zero. Once the rope was woven, its program could not be changed. Skilled workers at a Raytheon factory wove the ropes by hand, and some people called the result "LOL memory", a nickname that referred to the small group of women who did much of the weaving. An error found late in development could take weeks to fix, because the rope had to be rewoven.

Software engineering

Hamilton has said that she began to use the term "software engineering" during the Apollo years to describe what her team did. She wanted people to see that building software required the same discipline as designing hardware. Others were using the phrase around the same time, and a 1968 NATO conference gave it wide currency. Hamilton's contribution was to practice the idea on a project where the stakes were visible to everyone.

Her team treated the whole system as something to be engineered. They wrote specifications, reviewed one another's code and ran the software against simulations of the spacecraft. The simulations were crucial. The laboratory built test rigs in which the real computer ran against a model of the spacecraft, so that the code met realistic input long before launch.

The team also studied its own mistakes. When a bug appeared, the group looked for the kind of error it represented, then looked for the same kind elsewhere in the code. This approach later became common in software development, where it goes by names such as root cause analysis. Hamilton called the larger goal "zero defects", a phrase that reflects her belief that most errors could be prevented through better design.

A lesson from home

Hamilton often tells a story about her young daughter, Lauren, who sometimes visited the laboratory on weekends. While playing with the simulator, Lauren pressed keys and caused it to crash. She had started a pre-launch program in the middle of a simulated flight, which wiped out the navigation data.

Hamilton saw that an astronaut could make the same mistake in real life, and she asked that the software include a safeguard. NASA's reviewers decided that astronauts were well trained and would not make such an error, so the request was refused. On Apollo 8 in December 1968, astronaut Jim Lovell did select that program by accident during the flight. The mistake erased navigation data, and ground controllers and the crew had to reload the information. After that event, the software was changed to prevent the problem. The story shows Hamilton's stance: assume that people will make errors, and design the system so that a single mistake does not bring the mission down.

The asynchronous executive

The central feature of the Apollo software was its executive, the part of the program that decided what to do at any moment. The computer had to do many jobs at once, such as reading sensors, updating the position estimate, driving the display and controlling the engine. It could not afford to wait for any one of them.

The Apollo executive gave each job a priority. When the computer became overloaded, it did not freeze. It dropped jobs of low priority and kept the important ones going. The system could restart itself and recover from certain faults, resuming work from a saved point. These ideas are common in modern operating systems, but in the 1960s they were advanced, and the memory of the machine was tiny.

The design reflected a belief that failure was not rare. Instead of hoping that nothing would go wrong, the team built software that could survive the things that did.

The alarms on Apollo 11

On July 20, 1969, the Apollo 11 lunar module Eagle descended toward the Moon. A few minutes before landing, the guidance computer displayed program alarms numbered 1201 and 1202. Neil Armstrong and Buzz Aldrin did not know exactly what the numbers meant, and they reported them to Mission Control in Houston.

The cause was a mismatch in the setup of the lunar module's radars. The rendezvous radar, which was meant for a later phase of the mission, was left in a state that sent a constant stream of signals into the computer. The signals took up processing time that the landing program needed. The computer was becoming overloaded.

The alarms were the sign that the executive was doing its job. The computer was dropping low-priority work and restarting tasks, while keeping the landing guidance running. A young flight controller, Steve Bales, and a support engineer, Jack Garman, judged that the alarms were safe to ignore as long as they did not continue without pause. Bales called "go" and the landing went ahead. The astronauts landed safely.

It would be wrong to give the credit to one person. Hundreds of people at the laboratory, NASA and its contractors built the system, and Mission Control made the decision in real time. But the software's ability to survive an overload was the result of choices Hamilton's group had made years earlier. Hamilton has said that the event confirmed the approach her team had taken.

After Apollo

Hamilton left the laboratory in the early 1970s. In 1976 she co-founded a company called Higher Order Software with Saydean Zeldin. The company developed methods for describing systems so that errors could be found before the code was written. In 1986 she founded Hamilton Technologies, Inc., and developed an approach she named Universal Systems Language, along with a tool to apply it. The work continued her central interest in preventing errors by design instead of finding them after the fact.

The approach had supporters and skeptics. Formal methods of this kind are demanding, and most software companies have chosen lighter techniques. Still, the question that drove the work remains a live one: how can people build systems that stay safe when parts fail?

Recognition

For many years Hamilton's role was known mainly to people in the field. Recognition grew in the 2000s and 2010s. NASA gave her an Exceptional Space Act Award in 2003, which came with a payment for her contributions to the space program. In 2016 President Barack Obama presented her with the Presidential Medal of Freedom. The 1969 photograph of Hamilton beside a stack of printed code, which she did not stage as a symbol, became widely shared as an image of software work.

The stack of paper in the photograph is often described as being as tall as she is. It is a fair picture of what the Apollo software was: a large, careful, human-written body of work. The photograph shows listings for the guidance programs, and the pages represent the work of a team, not one person.

Why her story matters to a museum

Software leaves few objects behind. A museum can display a machine, and it can show the core rope memory, the printed listings and the astronaut's display and keyboard. These objects point to something that cannot be held: a set of ideas about how to make a system trustworthy.

Hamilton's career links three objects that a museum might show together. The SAGE console represents the era when software first ran a large system in real time. The core rope module represents the discipline needed when code could not be changed after it was made. The printed listings represent the human labor of writing and checking the program. Visitors can follow a line from one to the next and see how a field matured.

Her story also corrects an old assumption. Many people imagine that the space program was made of rockets and astronauts alone. Behind the hardware stood thousands of workers who wrote, tested and reviewed code, many of them young, and a good number of them women. Telling their story accurately gives credit where it is due, and it shows students that the field has always drawn on many kinds of people.

Questions for reflection

• Why did Hamilton insist that software deserved the name "engineering"?
• What does the story of the 1201 and 1202 alarms show about designing for failure?
• Which everyday devices depend on software that must not fail? How would you design them to recover from mistakes?