DSKY — Volume 11 — Margaret Hamilton and the Birth of Software Engineering

About This Volume

Of all the people who built the Apollo Guidance Computer, one face has become inseparable from the machine: a young woman in a patterned dress, smiling beside a stack of program listings nearly as tall as she is. The photograph is one of the most reproduced images in the history of computing, and the woman is Margaret Hamilton. This series uses that image elsewhere, where it serves as a kind of shorthand for the entire software effort. This volume is about the person behind it.

Hamilton’s reputation rests on two distinct achievements that have, over the decades, become braided together. The first is concrete and historical: she led the team at the MIT Instrumentation Laboratory that wrote and tested the on-board flight software for the Apollo Command and Lunar Modules — the code that ran inside the very computer this series is built around. The second is conceptual and arguably larger: she gave the work a name. She insisted, against ridicule, that what she and her colleagues did deserved to be called software engineering — a phrase that did not yet exist as a serious term of art, and that she used deliberately to claim for software the rigor, legitimacy, and accountability that hardware engineering already enjoyed.

This volume tells both stories, and the philosophy that connects them: a conviction, unusual for its era, that good software does not assume people will behave correctly. It assumes they will make mistakes — and protects against the mistakes they will make. That philosophy was not abstract. It was tested in flight, in a moment we will return to: the day an astronaut on Apollo 8, two hundred thousand miles from home, did almost exactly what Hamilton’s young daughter had done at play, and erased the spacecraft’s navigation data. The hardware and architecture of the AGC are covered in Volumes 6 and 7; the software and restart logic in Volume 10; the missions in Volumes 12–14; the Raytheon weavers who turned that software into physical wire in Volume 15. Here we concentrate on the woman, the word, and the worldview.

A Mathematician Finds Her Way to the Moon

Margaret Elaine Heafield was born on 17 August 1936 in Paoli, Indiana. She studied mathematics — first briefly at the University of Michigan, then at Earlham College, where she earned a bachelor’s degree in mathematics with a minor in philosophy in 1958. That pairing matters more than it might seem. The mathematics gave her the formal habits of mind that software would later reward; the philosophy gave her a taste for asking why a system was built the way it was, and what it meant for a process to be correct. She did not set out to be a programmer. In the late 1950s there was barely such a thing to set out to be.

Her entry into computing was almost incidental, as it was for many early programmers. In 1959 she took a position at MIT working for the meteorologist Edward Lorenz — the man who would later become famous for chaos theory and the “butterfly effect” — writing weather-prediction software on the LGP-30 and the early PDP-1. Lorenz acknowledged her contributions in his subsequent work. It was here that Hamilton first encountered the strange new craft of making a machine do something by feeding it instructions, and discovered she was good at it.

From 1961 to 1963 she worked on the SAGE air-defense project at MIT’s Lincoln Laboratory, writing software for the room-sized AN/FSQ-7 computers that watched American skies for Soviet bombers. SAGE was, at the time, one of the most demanding real-time software systems in existence — software that had to respond to events as they happened, that could not simply be re-run if it failed. There was a hazing tradition on the project: new programmers were handed the program nobody else had been able to make work, the one full of deliberately cryptic, undocumented code. Hamilton made it run. That reputation for taming intractable, mission-critical software is precisely what made her a candidate when the MIT Instrumentation Laboratory — Charles Stark Draper’s lab, which had won the contract to build the Apollo guidance system — went looking for programmers.

She joined the Apollo effort in the mid-1960s. She was, by most accounts, the first programmer hired for the on-board flight software at the Lab, and the first woman among them. She rose quickly. By the time the program reached its lunar climax she was leading the on-board flight software team and directing what the Lab came to call its Software Engineering Division — responsible for all the in-flight software of both the Command Module and the Lunar Module, and later for Skylab. Her remit spanned both spacecraft: the navigation, guidance, and mission-sequencing code that ran in the Command Module on the journey out and back, and the descent and ascent software — much of it the work of colleagues like Don Eyles — that flew the Lunar Module to the surface and off again.

Coining “Software Engineering”

The phrase we now use without a second thought — software engineering, an entire university discipline, a job title held by millions — had no settled meaning in the mid-1960s. Software was not yet a profession with standards. It was something clever people did, often brilliantly, often by the seat of their pants, and almost always without the documentation, review, configuration control, or accountability that any hardware engineer would have taken for granted. A bridge had engineers; a rocket engine had engineers; the code that would fly that rocket had… programmers, a word that carried no particular dignity.

Hamilton found this galling, and not for reasons of vanity. The software her team was writing was every bit as critical to the mission as the engines or the heat shield — arguably more so, since it was the software that would decide what the spacecraft did in a crisis. Yet it was treated as a soft, secondary, almost clerical activity. So she began, deliberately, to call it engineering. As she later put it, she “began to use the term ‘software engineering’ to distinguish it from hardware and other kinds of engineering, yet treat each type of engineering as part of the overall systems engineering process.” The point was not to wall software off but to admit it, as an equal, into the engineering tent — with all the rigor and responsibility that membership implied.

The reaction was not respect. It was laughter. “When I first came up with the term,” she recalled, “no one had heard of it before, at least in our world. It was an ongoing joke for a long time.” To the hardware engineers around her, putting software and engineering in the same phrase was a small absurdity, a category error, like calling a typist a structural engineer. She was, in effect, asking to be taken seriously in a vocabulary that did not yet exist.

The turning point, by her account, came in a meeting — when a respected senior hardware engineer, of all people, spoke up and agreed with her: that yes, what the software people were doing was a genuine engineering discipline, with its own demands and its own integrity. Coming from that quarter, the endorsement carried weight that her own advocacy could not. The joke began, slowly, to stop being a joke.

It is worth being careful with the history here, because legend tends to flatten it. The phrase “software engineering” was in the air more broadly in the late 1960s — a now-famous NATO conference in 1968 took the term as its title, deliberately provocative, to dramatize a “software crisis” of projects that ran late and failed unpredictably. Historians debate who first uttered the two words in sequence. What is not in serious dispute, and what this series asserts, is that Hamilton was among the earliest to use the term insistently and in earnest, on a real and unforgiving project, to argue that software deserved engineering’s discipline — and that her advocacy, more than almost anyone’s, helped the term shed its novelty and stick. She did not merely use the phrase. She lived the claim it made, on a project where the cost of unengineered software was measured in lives.

An Engineering Philosophy: Designing for the Mistakes Humans Will Make

If you want to understand why Hamilton fought for the word, look at how she practiced the thing. Her engineering philosophy had a single organizing conviction that ran through everything: a system must be designed around the errors that will actually occur, not the ideal behavior one hopes for. Hardware fails. Cosmic rays flip bits. Schedules slip. And — the part that made her unusual — people make mistakes, including the most highly trained people in the world, including astronauts, including under stress, including at the worst possible moment. Software that assumes its users will always do the right thing is not robust. It is merely lucky.

This translated into concrete design commitments that the AGC software embodied, and that Volume 10 treats in technical depth. The first was rigorous error detection and recovery — code whose explicit job was to notice that something had gone wrong and do something sensible about it, rather than blunder onward producing garbage. The second was asynchronous, priority-driven scheduling. The AGC did not run one task to completion and then start the next; it juggled many jobs at once, and when there was more work than the little computer could do, an executive — the design heritage here owes much to J. Halcombe Laning — would shed the low-priority work and protect the high-priority work, based on events as they happened rather than a fixed script. Each process had to be assigned, before the fact, a priority that captured its true importance. The third was the priority display concept: when the computer had to interrupt the crew, it did so in a structured, prioritized way that kept the human in the loop without drowning them in noise.

The deep payoff of this architecture arrives in Volume 12, during the landing of Apollo 11, when the AGC threw a cascade of 1201 and 1202 program alarms as it was overloaded with data — and, precisely because Hamilton’s team had built it to shed low-priority work and keep the essentials running, did not crash, did not abort the landing, and let Eagle continue to the surface. The alarms were not a failure of the software. They were the software working exactly as designed: recognizing it was overloaded, telling the crew, and protecting the jobs that mattered. That is robustness in the Hamilton sense — a system that degrades gracefully under stress instead of failing catastrophically.

Lauren, P01, and the Day the Worry Came True

The single anecdote that captures Hamilton’s philosophy better than any specification is small, domestic, and — in hindsight — almost eerie.

Hamilton sometimes brought her young daughter, Lauren, into the Lab on nights and weekends when there was no one to watch her at home. Lauren liked to play astronaut on the hybrid simulation computer, pressing the DSKY keys and pretending to fly the mission. One day, mid-”flight,” she did something no real astronaut was supposed to do: she selected P01, the prelaunch program, while the simulated mission was already underway in space. The simulation promptly fell apart. P01 was for initializing the system on the pad; running it in flight overwrote the data the navigation depended on. A child playing had found a way to break the spacecraft.

Hamilton’s instinct as an engineer was immediate: what if a real astronaut did this, in a real mission? It was exactly the kind of human error she believed software had to anticipate. She wanted to add code to the flight software to guard against it — a check to prevent P01 from being selected at the wrong time. The answer she got back is now famous, and revealing of the culture she was fighting: she was told it wasn’t necessary, because astronauts are trained professionals and would never make such a mistake. Not permitted to add the protective code, she did the next best thing available to her: she had a warning added to the program documentation — in effect, do not select P01 during flight.

Then came Apollo 8. In December 1968, the first mission to carry humans to the Moon and back, five days into the flight, the astronaut Jim Lovell — by any measure one of the most capable pilots alive — inadvertently selected P01. Exactly the mistake. The prelaunch program ran and wiped out the navigation data the computer needed to find its way home. It was not a simulation this time. Hamilton and her colleagues spent roughly nine hours combing through the thick program listings to devise a fix, then composed new navigation data to upload to the spacecraft, restoring its sense of where it was and bringing the crew home safely.

The lesson could not have been more pointed. The mistake that “no astronaut would ever make” had been made, on humanity’s first voyage to the Moon, by one of the best of them. Lauren, playing, had found the flaw months earlier. Hamilton had seen it, named it, and been overruled — and the universe had then proved her exactly right. After Apollo 8, the protection she had wanted was, of course, added. The episode became the cornerstone of her lifelong argument: robust software does not trust that humans will be perfect. It assumes they will err, and it catches them when they do. The astronaut is not the enemy of the system; the un-anticipated error is — and the engineer’s job is to anticipate it.

The Iconic Photograph

No account of Margaret Hamilton is complete without the photograph, even though this series deliberately reserves it for other volumes so as not to wear it out. Taken in 1969 at the Instrumentation Laboratory, it shows Hamilton standing beside a stack of source-code listings — the complete Apollo on-board software, printed and bound — piled so high that it reaches roughly to her shoulder or above. She is smiling, almost amused, one hand resting on the towering paper.

The image endures because it makes an abstraction visible. Software is invisible; you cannot photograph a program the way you can photograph an engine. But you can photograph the listings, and the sheer physical bulk of that paper stack delivers, instantly and without a word, the scale of the intellectual labor involved: hundreds of thousands of lines, every one of which had to be right, woven eventually into the core-rope memory by hand (Volume 15). For decades the photo circulated with no caption and no name; in the internet era it was rediscovered, attributed, and turned into a feminist and computing-history touchstone — the woman who, it is often said, “wrote the code that put men on the Moon.” That formulation flattens a team effort into a single hero, and Hamilton herself was always careful to credit the team. But as an image of what was at stake, and of who was responsible, it is unimprovable.

Recognition, Late and Large

For a long time, the recognition did not match the contribution. Hamilton left MIT in the 1970s and turned her Apollo-forged ideas about error prevention and reliability into commercial form. In 1976 she co-founded Higher Order Software with Saydean Zeldin, building a methodology and a tool called USE.IT around the goal of preventing errors before they could occur. In 1986 she founded Hamilton Technologies, where she developed the Universal Systems Language (USL) and its 001 Tool Suite, applying the same conviction — that reliability must be designed in, formally, from the start — to systems engineering far beyond spaceflight. She had become an entrepreneur of correctness.

The honors, when they came, were substantial. In 2003 NASA awarded her the Exceptional Space Act Award for her scientific and technical contributions; the prize included an award of $37,200 — at the time the largest sum NASA had ever given a single individual. And on 22 November 2016, in the East Room of the White House, President Barack Obama presented Margaret Hamilton with the Presidential Medal of Freedom, the highest civilian honor in the United States. The citation credited her with leading the team that created the on-board flight software for Apollo’s command and lunar modules, and with pioneering concepts — asynchronous software, priority scheduling, priority displays, human-in-the-loop decision capability — that “set the foundation for modern, ultra-reliable software design and engineering.” She received the medal in the same ceremony as the computing pioneer Grace Hopper, who was honored posthumously: two women who had, decades apart, insisted that software was serious business.

The Broader Team

Hamilton would be the first to insist that she did not do it alone, and honesty requires the same insistence here. The Apollo on-board software was the work of a large team at the Instrumentation Laboratory, and she led it rather than wrote it single-handed. J. Halcombe Laning designed the asynchronous executive whose priority-driven scheduling made the AGC’s grace under overload possible. Dan Lickly — whom Hamilton later married — worked on the re-entry and other software and was among her close collaborators. Don Eyles wrote much of the Lunar Module’s landing software, the code that flew the final descent (his story, and the 1202 alarms, belong to Volumes 10 and 12). Around them were dozens of programmers, many of them women, in an era when programming had not yet acquired the male-coded prestige that would later, ironically, push women out of it.

And there is a further circle of hands without which none of the code would have flown at all: the Raytheon weavers of Volume 15, the women — many of them experienced textile workers — who translated the finished software into physical reality by threading copper wire through or around tiny ferrite cores, one bit at a time, to manufacture the core-rope memory. “LOL memory,” some called it, for “Little Old Lady.” It is a chain of craft and rigor running from a mathematician’s insistence on a word, through a team’s discipline, to a weaver’s needle — and back up into orbit. Honoring Hamilton specifically, as this volume does, is not in tension with honoring them broadly. It is the same act. She gave the discipline its name; they, together, gave it its proof.

That proof flew to the Moon. And the next time the software had to prove itself — in the most public and most frightening way imaginable, in the final minutes of the first lunar landing, with alarms flashing and the world holding its breath — it held. That is where we go next.

Next — Volume 12: 1202 — The Alarms That Almost Stopped Apollo 11.