Though you might not recognize her name, you know Margaret Hamilton’s work, and you quite possibly know her face. She led the team responsible for the on-board flight software for the Apollo command module and lunar module. A black-and-white photograph of Hamilton standing next to a stack of code has reached iconic status, for reasons obvious: here is a woman pioneering the field of computer science at a time when the discipline was almost exclusively male; a laboratory director of software engineering before “software engineer” even existed as a job title; and an achievement to her name that defies comparison with any other human endeavor.

She didn’t stop at landing astronauts on the moon. She contributed also to Skylab, the first American space station, and to the space shuttle. In 1986, she founded Hamilton Technologies, Inc., a software development firm. Last year, she was awarded the Presidential Medal of Freedom for her work on the Apollo program and for her contributions in the field of computer science to “asynchronous software, priority scheduling and priority displays, and human-in-the-loop decision capability, which set the foundation for modern, ultra-reliable software design and engineering.”

A new picture book about Hamilton was published last month by Knopf Books for Young Readers. Written by Dean Robbins and illustrated by Lucy Knisley, Margaret and the Moon recounts Hamilton’s story and brings children to the harrowing landing of the Eagle. Computer science doesn’t come immediately to mind as a rich field from which children’s literature might grow, and yet Robbins and Knisley deftly tell a story that is at once moving and exciting. It is a testament to the skill of the author and illustrator that the book will be for many readers the first biography they ever read, an early introduction to the Apollo program, and an inspiring story of how science and engineering are done — and the book excels at all three.

In an interview by email, Hamilton tells me about her journey to the Apollo program, equality in STEM, and her contributions to the computer science discipline. It has been edited lightly for length and clarity.

Margaret Hamilton with her code (Credit: MIT Museum)

What were the circumstances of the famous photo of you standing next to that towering stack of code?

MHH: The photo was part of the information that MIT provided to the news media during the time of the Apollo 11 mission. The following was excerpted from a description of the photo in an MIT document: “Taken by the MIT Instrumentation Lab photographer in 1969…Margaret is shown standing beside listings of the software developed by her and the team she was in charge of, the Lunar Module (LM) and Command Module (CM) on-board flight software team”.

Each listing in the stack of listings contained Apollo guidance computer source code. For every mission there were two listings; one for the command module and one for the lunar module. Two of the listings were for Apollo 11, one for the Apollo 11 command module and one for the Apollo 11 lunar module. Other listings in the stack contained source code for future “to be” missions (e.g., Apollo 12, Apollo 13…) that we had been working on concurrently along with the source code for Apollo 11.

Is the Apollo program something that pursued you, or did you pursue it? In other words, how does one join the most ambitious engineering endeavor in human history?

MHH: At the time, I was working at MIT’s Lincoln Labs on the Semi-Automatic Ground Environment air defense system, developing radar registration surveillance software for detecting potential enemy planes, on the first AN/FSQ-7 computer (the XD-1). I had always planned to attend graduate school at Brandeis and major in abstract math, but I got sidetracked. Sometime within the 1963–1964 timeframe, I heard the news that MIT had received a contract from NASA to develop the software for “sending man” to the moon, and that MIT was looking for people to work on this project. I immediately called MIT to see if I could be involved in what sounded like the opportunity of a lifetime. Within hours, I set up interviews with two project managers at MIT. Both of them offered me a position on the same day as the interviews. I did not want to hurt anyone’s feelings, so I told them to flip a coin to decide which group would hire me — hoping for the project manager to win the coin toss, who, in the end, did win. Fortunately, that is what happened, and I was on my way.

There is a greater effort today to correct the gender imbalance in the fields of STEM. What advice would you give to aspiring scientists and engineers?

MHH: The type of experience and education one has before entering the fields of STEM as well as other fields is key. I have found it helps to have both a “streetwise” experience and a formal education. From a streetwise perspective, the more jobs a young person has (and the more varied), the better prepared one is for going out into the world. Learning how to work with and getting used to being around different kinds of personalities and challenges helps one to have the flexibility needed to understand others, and to deal with the unexpected. It provides a better foundation from which to make career choices, including who you choose to work with and for whom you choose to work.

Regarding the formal part of education, one would of course want to take courses directly related to the particular field of STEM of interest (e.g., computer science). But, it is also important to learn and be around other kinds of things like music, art, philosophy, history and formal linguistics; any of which could help improve one’s being an excellent problem solver; and to have a more global perspective on things. The ultimate goal is learning how to think.

Women cannot be expected to solve the gender imbalance problem alone — especially on an individual-by-individual basis. Too often it is the symptoms of the problem that are being addressed by well-meaning efforts today, when the real problem has been and still is our culture. Things are still being done (and accepted as such) out of ignorance. It is not uncommon for an organization to pay women lower salaries than men for the same position, and to relegate women to the lower positions in an organization. And if not, women often have to work or fight harder than their male counterparts to be an exception. Most would agree that the STEM fields are still dominated by men; that discrimination does exist. In fact, some things seem to have gone backwards and are more difficult now than they were in the sixties. Some ways in which discrimination manifests itself can be quite different today — especially now that we have the internet.

Unfortunately, various types of communication over the internet can serve as convenient places to “hide” in, encouraging “faceless,” pervasive practices, making it harder than in earlier days to confront those intent on perpetuating disinformation that can be quite harmful to those on the receiving end. A case in point is the use of historical revisionism, in any form conceivable, to minimize the accomplishments of an individual or a group of individuals; a not uncommon practice when it comes to the affect it has on women and minorities. Solving just this one part of the problem, itself, is indeed a challenge that can only be totally addressed at large.

One seemingly small event can change everything, for better or worse, because everything is somehow related to everything else. When the most powerful and influential leaders and organizations in the world make it possible for women to hold the highest positions (not “almost” the highest) in their organizations equal (not “almost” equal) to what is available to men, we all benefit, including the leaders and organizations themselves. When large corporations refuse to conduct business with and within countries who do not allow women to have the same rights as men, we all benefit. The more all of us work to uncover discriminatory practices and the more those in power promote non-discriminatory practices as being a positive thing, the more we all benefit.

Margaret Hamilton in an Apollo command module (Credit: NASA)

What most worried you during development of the Apollo software, and how did you and your team solve it?

MHH: The greatest challenge was that our software had to be man-rated; which meant lives were at stake. Failure was not an option. Not only did it have to work; it had to work the first time. Not only did the software, itself, have to be ultra-reliable, but the software would need to be able to detect an error and recover from it in real time. It did not disappoint.

The task at hand included developing and integrating all of the software for the command module, the lunar module and the systems software shared between, and residing within, both the command and lunar module; making sure that everything would play together and that there were no integration, communication, or interface conflicts (i.e., data, timing or priority conflicts). Updates, submitted from hundreds of people, were continuously being made over time and over the many releases for every mission; making sure that the software would successfully interface to, and work together with, all the other systems including the hardware, peopleware and missionware.

Because of the never-ending focus on making everything as perfect as possible, anything to do with the prevention of errors was not only not off the table, but it was top priority both during development and during real-time where it was necessary to have the flexibility to be able to detect anything unexpected and recover from it at any time in a real mission. To meet the challenge, the software was developed with an ongoing, overarching focus on finding ways to capitalize on the asynchronous and distributed functionality of the system at large in order to perfect the more systems-oriented aspects of the flight software. Such was the case with the flight software’s system-wide snapshot rollback capabilities and priority displays together with its man-in-the-loop techniques. Our software was designed to be asynchronous in order to have the flexibility to handle the unpredictable, and in order that higher priority jobs would have the capability to interrupt lower priority jobs, based on events as they happened (especially in the case of an emergency).

Each mission was exciting in its own right, but Apollo 11 was special; we had never landed on the moon before. Just as the astronauts were about to land on the moon, everything was going according to plan until something totally unexpected happened. All of a sudden, the on-board flight computer became overtaxed. The software’s priority displays of 1201 and 1202 alarms interrupted the astronaut’s normal mission displays to warn them that there was an emergency, allowing NASA’s Mission Control to understand what was happening, and alerting the astronauts to place the rendezvous radar switch in the right position. The priority displays gave the astronauts a go/no go decision (to land or not to land).

It quickly became clear that the software was not only informing everyone that there was a hardware-related problem, but that the software was compensating for it. With only minutes to spare, the decision was made to go for the landing. The rest is history. The Apollo 11’s crew became the first humans to walk on the moon, and our software became the first software to land on the moon. An explanation of what happened, and the steps taken by the on-board flight software to “continue on” to landing are briefly described in my letter to the editor, “Computer Got Loaded”, published in the March 1, 1971 issue of Datamation.

The development and deployment of this functionality would not have been possible without an integrated system of systems (and teams) approach to systems reliability and the innovative contributions made by the other groups to support our systems-software team in making this become a reality. The hardware team at MIT changed their hardware and the mission planning team in Houston changed their astronaut procedures, both working closely with us to accommodate the priority displays for both the command and lunar modules for any kind of emergency and throughout any mission. In addition, the people at Mission Control were well prepared to know what to do should the astronauts be interrupted with the priority displays.

Since it was not possible (certainly not practical) on Apollo for us to test the software “before the fact” by flying an actual mission, it was necessary for us to test our software by developing a mix of hardware and digital simulations of every (and all aspects of an) Apollo mission which included man-in-the-loop simulations (with real or simulated human interaction); and variations of real or simulated hardware and their integration.

Astronauts who have walked on the moon often describe a certain listlessness once they get home. As an engineer key to that achievement, are you left with a similar feeling? What sort of feeling follows?

MHH: Of course, I would be hard put to even begin to compare feelings of my own to that of an astronaut who walked on the moon! Do you mean by a certain listlessness that I may have experienced a letdown or feeling of depression, because of the fact that nothing could ever follow that could be as exciting? I do not remember a time, following a major event (like landing on the moon) or a major project (like Apollo), when there was a real chance (or when I took a chance) to reminisce and miss the action. There was always something happening immediately thereafter that seemed to be exciting in its own right.

I have always been more “wrapped up” than not, with wasting little time in capturing lessons learned from an experience and doing something about it so that we could apply that knowledge on the adventures to follow. Towards this end, I have found that it helps to focus on learning from the past, not living in it. There was always an adventure to follow that would have its own kind of excitement. I do want to say, however, that what we have been doing over the years with our computer science-related work is much more exciting because of the lessons we learned from Apollo.

Describe your work on Skylab and the space shuttle.

MHH: Skylab was a continuation of the Apollo command module on-board flight software, with new software added for new Skylab requirements. We defined systems software requirements for the Skylab and the Space Shuttle on-board flight software as a result of many of the lessons we had learned from Apollo. Among other things, we performed an empirical study of the Apollo on-board flight software development effort, resulting in formalizing lessons learned. Part of the requirements for Skylab and the Space Shuttle originated from this work.

As a pioneer in the field, what would you say is your greatest contribution to the discipline of computer science?

MHH: For whatever success I have experienced in my work, the credit goes not only to those I have learned so much from and have worked with, but also to the errors I have had the opportunity of having had some responsibility in making, without which we would not have been able to learn the things we did — some with great drama and fanfare, and often with a large enough audience to not want such a thing to ever to happen again!

Having been through some amazing experiences such as those involved with the Apollo on-board flight software, one could not help but do something about learning from them. With initial funding from NASA and the Department of Defense (including the Air Force, the Navy, and the Army), we performed an empirical study of the Apollo effort. This resulted in a systems theory, based upon a concept of control, that has continued to evolve based on lessons learned from Apollo and later projects. From its axioms, we derived a universal systems language together with its automation and its preventative development paradigm.

Margaret Hamilton poses with an MIT pennant inside an Apollo lunar capsule model. (Credit: MIT Museum)

We continue to discover new properties in systems defined with this language. Among other things, we learned that with the use of the language there are no interface errors in a system definition and its derivatives (one of which is its software); and integration within a definition, and from systems to software, is inherent. Along the way, it became clear one day that the root problem with traditional approaches is that they support users in “fixing up wrong things” rather than in “doing things in the right way in the first place.” With a preventative paradigm, instead of looking for more ways to test for errors, and continuing to test for errors late into the life cycle, the majority of errors including all interface errors are not allowed into a system in the first place, just by the way it is defined. Testing for non-existent errors becomes an obsolete endeavor. For each new property discovered, that, in essence, “comes along for the ride,” there is the realization of something (e.g., testing for interface errors) that will no longer be necessary as part of the system’s own development process.

Margaret and the Moon: How Margaret Hamilton Saved the First Lunar Landing was written by Dean Robbins and illustrated by Lucy Knisley. It is available in bookstores everywhere.