The first person to be highlighted in the Luminary series is someone named Margaret Hamilton. While you may not be aware of whom this post is about here at the beginning, this is a person that has had great influence over the profession of Software Engineering and is worthy of recognition by all who claim that title. To start, let’s take a look at a picture that might be more recognizable than the name.
Margaret Hamilton is one of a number of people that are on the list of Luminaries that I want to highlight. When reviewing the list and doing some light research on the people contained therein I stumbled upon her birthplace which happens to be Paoli, IN. As a fellow Hoosier and Engineer, that was all it took to propel her to the top of the list.
Instead of rehashing a biography, I would like to encourage any readers to do your own research. I promise to only highlight people that are worthy of spending an hour or two reading about. Therefore, here are some quick links and info to help get you started:
- Wikipedia: Margaret Hamilton (software engineer) (WPC Score: 15)
- Birthplace: Paoli, IN in 1936
- Current Company: Hamilton Technologies
- Achievements & Awards: at age of 28 was the first programmer that NASA hired; 1986 Ada Lovelace Award; 2003 NASA Exceptional Space Act Award, 2016 recipient of the Presidential Medal of Freedom from President Barack Obama; 2017 featured in the Lego minifig set: Women of NASA
- Note: Do not get Margaret H. Hamilton confused with Margaret B. Hamilton who happened to play the Wicked Witch of the West in the Wizard of Oz!
The Mother of Software Engineering
Simply put, if you write software and call yourself an Engineer then you owe your job title to Mrs. Hamilton. She is credited with coming up with the term Software Engineering. Like many disciplines, Engineering has hierarchies amongst the people who are practitioners of the art. While in school for Engineering myself I remember our generalized ranking of Engineering disciplines. Chemical Engineering? That stuff is really hard – much respect. Mechanical? They have to take thermodynamics, so give them some respect. Civil? Ha! Who wants to be a Poop Engineer and go design waste management systems. Industrial? Well, someone has to be at the bottom of the totem pole. Please note that I say the above in jest as I have great respect for anyone that has the ability to successfully make it through a modern Engineering program. There is nothing easy about it – no matter what discipline is being learned.
The thing that is amazing is that there were no schools for Computer Engineering of any kind for Mrs. Hamilton to attend. In 1959 when she and her husband moved from Indiana to Boston, MA there was no Computer Science or Computer Engineering at the place that she ended up working for. You might have heard of it, just a little place called MIT. The term Software Engineering hadn’t even been coined yet when she started working there. So when she worked herself into a position at NASA as the lead developer for Apollo flight software there happened to be a pecking order to follow. This turned out to be hardware first, software second.
It is this pecking order that was in place at the time that drove Mrs. Hamilton to start using the term Software Engineering. She recounts in an interview posted on Medium that:
I fought to bring the software legitimacy so that it (and those building it) would be given its due respect and thus I began to use the term “software engineering” to distinguish it from hardware and other kinds of engineering
Margaret Hamilton in an interview on Medium with Jamie Rubio Hancock for Verne
However, her place as the lead developer on a project of this importance was one of the reasons that her efforts, which were initially treated as a joke with people referring to it as a radical idea, eventually led to the discipline gaining respect. Another factor in favor of software in regards to gaining respect is that the Apollo missions were one of the first major, high profile, instances where software was trusted is such a mission-critical manner. And not just any run-of-the-mill critical real-time application of software, one that was led by none other than Margaret Hamilton.
She was not just a leader, she was a pioneer in many aspects of Software Engineering. While working at MIT, pretty much everything was new and being created from the ground up. There was no roadmap or blueprint to follow, being a pioneer was not a choice, it was required in order to move things forward.
The working environment was very much like the rest of MIT. Informal, but serious. Because software was a mystery, a black box, to upper management, we were given total freedom and trust. Mutual respect was across the board. We were very lucky to be in the right place at the right time.
Margaret Hamilton in the article: Margaret Hamilton: The Untold Story of the Woman Who Took Us to the Moon
Besides her contributions and accomplishments around the Apollo missions with NASA, Mrs. Hamilton has continued to contribute to the field of Software Engineering through the businesses that she created, fist with Higher Order Software that create a product called USE.IT based on the HOS methodology that she helped develop while at MIT. This methodology is captured in a paper that Mrs. Hamilton co-authored:
The key to software reliability is to design, develop, and manage software with a formalized methodology which can be used by computer scientists and applications engineers to describe and communicate interfaces between systems. These interfaces include: software to software; software to other systems; software to management; as well as discipline to discipline within the complete software development process. The formal methodology of Higher Order Software (HOS), specifically aimed toward large-scale multiprogrammed/multiprocessor systems, is dedicated to systems reliability.
M. Hamilton & S. Zeldin: Higher Order Software – A Methodology for Defining Software
In 1985 Mrs. Hamilton left HOS and a year later started Hamilton Technologies, Inc. where she continues to pioneer Software Engineering methodologies through the use of Universal Systems Language (USL), a modeling language and formal method for the design of software that she created based off her Apollo experiences and Development Before The Fact (DBTF) which is “a system planning, design and software development paradigm where each system is defined with properties that control its own design and development, in essence “performing” its own development. Such a system can be thought of as having built-in quality and built-in productivity. With this paradigm, an emphasis is placed on defining things right the first time. Problems are prevented before they happen. Each system definition not only models its application but it also models its own life cycle” (per the glossary on the Hamilton Technologies website).
The Apollo Missions
The iconic picture of Margaret Hamilton standing next to a stack of books containing code used in the Apollo missing is not staged in any way. Mrs. Hamilton herself certifies the authenticity of 100% code in an article on Vox (Meet Margaret Hamilton, the badass ’60s programmer who saved the moon landing) by confirming ” To clarify, there are no other kinds of printouts, like debugging printouts, or logs, or what have you, in the picture.”
To understand better the value and importance of her work on the Apollo missions, a little background information is needed. This may seem a little strange to younger readers who have never experienced what computing was like before cellphones were universal and most people have access to personal computers. Way, way back in the 1950’s and 1960’s a computer was not available at every desk. In fact, a computer wouldn’t even fit on a desk. Back then most computers took up entire rooms and had no screen interfaces for easy access. In order to program and use a computer, programmers would have to create their program on punch cards, feed them into the machine and sit back and wait for the outcome. This could be nerve wracking as a computer crash during program execution was not a quiet event. This type of crash would be accompanied by alarm bells, flashing lights, and many people coming to see whose program had cased all of the commotion.
Mrs. Hamilton worked on these large computers while helping to create a very early form of homeland security while working on the SAGE system at Lincoln Labs at MIT. (SAGE: Semi-Automatic Ground Environment Air Defense System. WPC Score: 13) The goal of the system was to search for unfriendly aircraft using a XD-1, the first AN/FSQ-7 computer. To illustrate just how big these early computers were, wikipedia states that the machines used were “the largest discrete computer system ever built, each of the 24 installed machines weighed 250 tons. The AN/FSQ-7 used a total of 60,000 vacuum tubes (49,000 in the computers) and up to 3 megawatts of electricity, performing about 75,000 instructions per second for networking regional radars“.
SAGE was important for Mrs. Hamilton in that she states that is where she started to become interested in software reliability. At the time, debugging was much harder than it is today. The only information available to the programmer was the computer lighting up the specific register on the console of the computer showing the address of where the program had halted. Mrs. Hamilton was able to grow her knowledge around reliability and create new debugging options from an idea that she came up with from one of her programs that she called the ‘seashore program’. In her own words:
When my program was running, it always sounded like the sound of waves on a beautiful seashore, so we all referred to it as the ‘seashore program.’ Until one night at 4 am in the morning when I got a call from one of the computer operators who said something terribly wrong has happened with your program. When I asked him how he knew, he said ‘it no longer sounds like a seashore!’ Now, we had a new way to debug, using sound!
Margaret Hamilton in the article: Margaret Hamilton: The Untold Story of the Woman Who Took Us to the Moon
It should also be noted here that in order to create the ultimate reliability while in space, the software could not be re-flashed or re-loaded onto the computers in the LM and CM. These computers weighed in at 70 pounds apiece and contained ‘ropes’ of wire consisting of woven copper wire and magnetic cores that depending on the weaving represented 1’s and 0’s for the code. Due to the tedious nature of this entire endeavor, a sense of humor was a good thing. Once programs were finalized they were handed off to LOLs, short for Little Old Ladies, who would create the ropes. FLTs, or Funny Little Things, represented mysterious minor bugs in the software. Mrs. Hamilton herself was branded with the term ‘rope mother’. “And you debugged a program by the “Auge Kugel” method. That is the German phrase for eyeball. In other words, you looked at the listing and tried to read it as if you were a computer. Some might not think that was proper engineering practice, but it worked” (article: The “Rope Mother” Margaret Hamilton).
Fast forward a few years and Margaret Hamilton was working on the guidance and control systems for the lunar module and the command module for the Apollo missions. It should be noted that the Apollo program spacefllights actually started with Apollo 7, which was a crewed mission in Earth orbit. That was followed by an Apollo 8 command module-only orbital mission to the moon, Apollo 9 testing out the lunar module (LM) and command module (CM) together in Earth orbit, and Apollo 10 lunar orbit mission with both modules together. We all know what came next in July of 1969. Neil Armstrong and Buzz Aldrin in the LM made it safely down to the surface of the moon and returned to the CM where Mike Collins was waiting and together the three of them made their way safely back to earth. An amazing feat on its own, but it is all the more remarkable when you hear the story of how close the lunar landing was to being scrapped and how the software of one Margaret Hamilton saved the day.
Before the software reliability that saved the first lunar landing with humans aboard, the Apollo program had already benefited greatly from this methodology when during the Apollo 8 mission when Jim Lovell inadvertently deleted all of the navigation data from the onboard computer. Mrs. Hamilton should receive the credit for the implementation of a solution in software for this potential disaster, but she has to share credit for the identification of the problem with her daughter, Lauren. At the time when she was working on the Apollo code Mrs. Hamilton was only in her mid 20’s and would bring her daughter to work to spend more time with her. When asked about work-life balance during the Apollo project she states: “Being young helped! Also, I made sure to spend as much time as possible with my daughter by taking her to work with me during nights and weekends.” (article: Margaret Hamilton: The Untold Story of the Woman Who Took Us to the Moon). In this instance, it also helped to save Apollo 8.
While watching her mother test her code by simulating what astronauts would do in the LM and CM, Lauren would also play at being an astronaut. One day this aspiring astronaut caused the whole system to crash by selecting the pre-launch program, P01, while a simulation was mid-flight. Leave it to a child to show the reality that is Murphy’s Law. Unfortunately, NASA did not see the need to add protection for an event like this because in their own words, “astronauts never make mistakes – they trained to be ‘perfect’ ” (article: Margaret Hamilton – her code got humans on the moon). From the same article, Mrs. Hamilton recalls: “I said, oh my god, this is not good. We really need to put protection in there, because the astronaut really could do what she did by mistake.” She won the battle and led the effort to add software reliability into the Apollo program they also added a program note in the documentation for all engineers and astronauts: “Do not select P01 during flight“. These words turned out to be prescient because this is exactly what Jim Lovell inadvertently did on the Apollo 8 mission – and the work paid off as the error was corrected and allowed the mission to proceed and ultimately be successful.
When Apollo 11 rolled around the knowledge and solutions in place were probably the most robust and error-tolerant systems ever created to that point in time. Mrs. Hamilton was more critical of herself than the bureaucratic requirements put on her by the NASA brass. She comments in various interviews about a fear of an error occurring and it being traced back to the software, and ultimately, to her. This bolstered her belief in the idea of software reliability, stating:
The space mission software had to be man-rated. 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, it needed to be able to perform error detection and recovery in real time. Our languages dared us to make the most subtle of errors. We were on our own to come up with rules for building software. What we learned from the errors was full of surprises
Margaret Hamilton in the article: What to Know About the Scientist Who Invented the Term “Software Engineering”
All of this came to a head on the Apollo 11 mission. When it came time to land the LM on the surface of the moon, an incorrect checklist led the astronauts to incorrectly have the switch for the rendezvous radar in the on position. This led to an overflow of data to the landing computer (an estimated 90% from the landing system and 13%-15% from the radar system). Mrs. Hamilton summarized the process flow thusly: “Every time the CPU approached overload, the software cleared out its entire queue of processes, restarted its functions; allowing only the highest priority ones to perform until the landing was completed” (article: Margaret H. Hamilton: Apollo Computer Programmer). Because of the reliability built into the system, the computer was able to alert the astronauts with error codes 1201 and 1202 and then drop the lower priority tasks in favor of the more important landing system. The astronauts followed by trusting the computer code and making a critical ‘Go’ decision that led to the moon landing with less than 30 seconds of available fuel remaining. This methodology allowed not only the Apollo 11 landing to be successful, but ultimately paved the way for the Apollo 12, 14, 15, 16, and 17 landings (the Apollo 13 landing having been aborted due to an explosion in the CM en-route to the moon).
In referencing the events around the Apollo 11 landing, Mrs. Hamilton appreciated the work leading up to the mission as much, if not more, than the excitement of the successful resolution of the problems encountered during the landing:
From my own perspective, the software experience itself (designing it, developing it, evolving it, watching it perform and learning from it for future systems) was at least as exciting as the events surrounding the mission
Margaret Hamilton in the article: Margaret H. Hamilton: Apollo Computer Programmer
Why Women in Tech Matter
The intent of this post is not to delve into the many reasons why women are under-represented in technical fields, not is there any intent here to provide a thorough analysis of how this realty came to be. But it would be amiss when talking about Mrs. Hamilton without touching on the topic of representation in engineering and technical fields.
If your image of a NASA engineer or scientist is that of a white male in a crisp white shirt with black clip-on tie and pocket protector, think again. NASA has evolved and so has it workforce. Drawing on the talents of individuals from all nationalities and cultural backgrounds, NASA is looking to acquire the best of what humanity has to offer.
NASA Engineers and Scientists-Transforming Dreams Into Reality by A.J.S. Rayl
This statement comes directly from a article celebrating NASA’s 50 years of exploration that occurred between 2007-2008. This is a message evocative of the image of Ed Harris as Gene Kranz in the control room in the movie Apollo 13 with his hardworking crew. “The engineers weren’t all boys with crewcuts, short sleeve oxford shirts, and narrow black ties. That’s just a fairy tale they told for a while” (Dave Reneke, from: She Wrote The Code For The Moon landing in 1969). We know from the information available about Mrs. Hamilton that at least one of the pivotal people on the Apollo missions was female. There just wasn’t one outlier here – there were many people of all different genders and races that provided important contributions to the feat of putting a human on the moon (Easy example: Hidden Figures (book, Amazon referral link) and movie). This also should not take anything away from the amazing accomplishment of humanity putting a representative member of our species on another object in space. These people were all heroes. The criticism here is that when creating a movie to celebrate these achievements in Apollo 13 the contribution of females in this drama are relegated to that of the apprehensive spouse or daughter of one of the men doing the dangerous work. It is not my intent here to comment on the social structure that led to only men being on the Apollo 13 mission, but we know that women worked on the software and systems of the spacecraft, so would it have hurt to show a few of them helping out in figuring out the power on sequencing that was critical to getting those men back to earth safely?
Please understand the intent here. This is not a criticism of white-man-washing at NASA. We know that the typical employee at NASA over the past 50 years is a white man. NASA’s own statement (quoted above) for their own 50th anniversary celebration indirectly calls out this fact. Margaret Hamilton calls it out thusly:
There were many more men than women in our profession, and this is still the case. Regarding my own experiences, women were always in the minority and men were always in the majority. Before and during Apollo, my colleagues, including those on the software engineering team, for which I was responsible, were mostly male.
Margaret Hamilton: The Untold Story of the Woman Who Took Us to the Moon
Current statistics at NASA in 2019 show that females make up about 1/3 of the workforce and approximately 28 percent of senior executive leadership and merely 16 percent of senior scientific employees. Even though in their own words, ” NASA is looking to acquire the best of what humanity has to offer ” the fact is that these ratios are not changing very quickly.
“We haven’t moved very much in the last 30 years in overall diversity,” said Mary Lynne Dittmar, the president and CEO of the Coalition for Deep Space Exploration, an industry group. “Aerospace is still heavily male and white, and we’re not moving very quickly.”
Stats and quote from: At NASA, 2019 was the year of the woman, yet women still are a big minority at the space agency
What is the point of calling out all of these stats and seeming to bash on my own gender for the past few paragraphs? The point is that humanity is on a path where Engineering, computers, and software pave the way for technological advancements in our society, yet the people coming up with these advancements do not represent our society as a whole. We live on a planet one meteor strike away from extinction. We are dealing with the most rapidly evolving climate change ever witnessed (and caused) by human beings yet we are barely applying a little more than 50% of our available people against these problems to come up with solutions. We don’t need to force more people of certain classifications into these fields – we just need to make the opportunities equal for anyone, female or male, black or white, left-handed or right-handed to pursue the work that interests them.
She has this mentality that there should be equal rights and equal access. And it wasn’t about men and women. It was about people being able to pursue the kinds of jobs they want to pursue and take on the challenges they want to take on
Teasel Muir-Harmony from the article: Margaret Hamilton Led the NASA Software Team That Landed Astronauts on the Moon
When we create these opportunities for people, no matter how those people are classified or identified, success will follow. Once someone is in the role and doing their job these differences do not matter in the real world. Mrs. Hamilton shows this effect in her own words:
In the case of the Apollo project my colleagues (mostly male) and I were friends and we worked side by side to solve challenging problems and meet critical deadlines. We concentrated on our work more than whether one was male or female. We were more likely to refer to someone as a “second floor person”, “a hardware guy”, “A DAP person”, “an operating system guru” or a “rope mother (where the rope mother could be a male or a female)”.
Margaret Hamilton from the article: Margaret Hamilton, the Engineer Who Took the Apollo to the Moon
Is it as simple as a basic Field of Dreams philosophy? If we built it they will come? Maybe some paraphrasing is in order: If we provide equal opportunities, then they will come. This is not an answer to a very complex issue, but what is stated here could represent the first steps down the path to a solution. For anyone reading this looking for advice about following in the footsteps of Margaret Hamilton, I will defer to her own words on this topic:
Finally, what piece of advice would you give you young girls who are interested in pursuing a STEM career?
MHH: Regarding one’s education related to any field, I think it is important to bring together what I would call the necessary experiences for both a ‘streetwise and a formal education. From a streetwise perspective, the more jobs a kid has, and the more varied they are, during his or her youth, the better prepared one is for going out into the world. When considering the formal part of a kid’s education, learning subjects like English and other languages, history and STEM [science, technology, engineering and math including logic], including how to use computers…this is important in preparing for all parts of our modern society.
Software engineering related courses are important for all aspects of STEM including that of helping one to become more creative, a better problem solver—including being a good detective and how to understand the world in terms of a system of systems—to learn how to be analytical and objective, about abstraction, and how to think outside of the box. How to learn from your mistakes and turn that into a positive result can also be learned from software engineering related courses. I believe it is also important to learn (or be around) things like music, art, philosophy, linguistics, and math including logic; any of which could help improve one’s being an excellent programmer/problem solver/thinker and to have a more global perspective on things. The ultimate goal would be that of teaching one how to think (design).
I would add that what seems to work best for me when I want to learn about anything new or to do anything new is not to let fear get in the way.
One should not be afraid to say ‘I don’t know’ or ‘I don’t understand,’ or to ask ‘dumb’ questions, since no question is a dumb question. To continue even when things appear to be impossible, even when the so called experts say it is impossible; to stand alone or to be different; and not to be afraid to be wrong or to make and admit mistakes, for only those who dare to fail greatly can ever achieve greatly.
Margaret Hamilton from the article: Margaret Hamilton: The Untold Story of the Woman Who Took Us to the Moon
I couldn’t have said it any better myself. In closing, I would like to express a heartfelt thank you to Margaret Hamilton, for your work and inspiration to all of us who aspire to the lofty title of a Software Engineer. It is my hope that one day your story will continue to grow through subsequent generations of young Engineers who don’t have a playbook or curriculum to follow and who are forced to make up and live by their own rules, not from a sense of want, but from a sense of need in order to push the boundaries and explore the next frontier.
This article is part of a series of pieces dedicated to highlight Luminaries. These people have shined their light across humanity in a positive and beneficial way. These are not meant to be comprehensive biographies – so if any of the information here sparks any interest then I greatly encourage you to pursue additional research of your own for these amazing and enlightening people. Any errors in quoting, misinterpretation of intent or ideas, or mis-characterizations of people are mine and mine alone. Thank you for reading!
Comments are closed, but trackbacks and pingbacks are open.