Margaret Hamilton’s impact on computing would be hard to overstate. For one thing, I nearly wrote “impact on software engineering” but apparently that’s a term she had a lot to do with promoting, during her tenure at NASA.

Hamilton did see computing as an engineering discipline – she had early experience that made her understand that software is not just coding a “pong” game; reliability is not just an option when you’re coding the control software for a manned lunar rocket. I wish the Internet Of Things programmers of today understood what Margaret Hamilton understood in the 1960s.

This was the “bearskins and flint knives” era of computing: magnetic core, paper punch tape, 24k of memory. Programmers wrote code in pencil, then typed it in, fixed the syntax errors, and tested it. Application frameworks were nonexistent; you wrote each application from the ground up and programmers were still in the process of figuring out what parts of a software system were common and shared, versus project-specific.

Richard Feynman, writing about the software in the Challenger disaster,* said:

The software is checked very carefully in a bottom-up fashion. First, each new line of code is checked, then sections of code or modules with special functions are verified. The scope is increased step by step until the new changes are incorporated into a complete system and checked. This complete output is considered the final product, newly released. But completely independently there is an independent verification group, that takes an adversary attitude to the software development group, and tests and verifies the software as if it were a customer of the delivered product. There is additional verification in using the new programs in simulators, etc. A discovery of an error during verification testing is considered very serious, and its origin studied very carefully to avoid such mistakes in the future. Such unexpected errors have been found only about six times in all the programming and program changing (for new or altered payloads) that has been done. The principle that is followed is that all the verification is not an aspect of program safety, it is merely a test of that safety, in a non-catastrophic verification. Flight safety is to be judged solely on how well the programs do in the verification tests. A failure here generates considerable concern.

Margaret Hamilton’s work was significant not simply because she was responsible for the code for the command module and the LEM, but because she figured out how reliable software is developed. The methods that she helped pioneer are the methods that are used today in the development of critical control systems for aircraft and industrial systems. Next time you’re napping at high altitude in some modern jet, you may spare a thought for how casually you’re trusting your life to complex flight control software, written by very fallible humans. Reliability became Hamilton’s life’s work.

The Apollo missions were flown before there were operating systems that aggregated common/core system services behind standardized programming interfaces.** The spacecraft ran applications that were loaded and unloaded specifically from punch-tape: now it’s time to load your “how to land” software! Each piece of software was basically a control-loop that monitored multiple inputs and outputs, and had to prioritize where it was spending its CPU cycles – stuff that’s all done automatically in the bowels of an operating system (it’s called the process scheduler, in most O/S now) the software flying the Apollo missions had to figure that all out using a technique called pre-emptive scheduling. That’s basically like the way iOS or a smartphone appears to work: whatever app is at the “top” of your screen has most of the CPU’s attention, and all of the user inputs and interactions, with the home/attention button serving as a wakeup to the scheduling executive.

Hamilton realized that part of system design was figuring out special cases for where the system needed to deal with something expected, as well as figuring out general cases where the system encountered something unexpected, but had to do the right thing. At one point during the Apollo landing, the system began spuriously spitting a distracting stream of error warnings, which suddenly cut off at the point where the system had been programmed to detect that it was in mid-landing and needed to shut off extraneous processing in order not to distract the pilot. The best programmers today still engage in such “defensive programming” – not just assuming things will go right, but predicting how they may go wrong, and having stable operations the code can fall back to when it gets into an unexpected state.

After the space program, Hamilton went on to start a business oriented toward “Higher Order Software”***  She tried to teach other people how to do it right. The idea of modular software developed with cooperating function and architectural specifications lives on. Hamilton’s co-evolved with general systems theory – the idea that architecture and systems could be decomposed and reasoned about bottom-up and top-down – which became part of the structured software development model of the 1980s; a model now seen as slow and ossified. Today’s “agile” and “rapid” development is a direct reaction to the costs and time involved in producing structured architectures. And, if you’ve used “Internet Of Things” devices, you can see the proof is in the pudding.

“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. … There was no second chance. We knew that. We took our work seriously, many of us beginning this journey while still in our 20s. Coming up with solutions and new ideas was an adventure. Dedication and commitment were a given. Mutual respect was across the board. Because software was a mystery, a black box, upper management gave us total freedom and trust. We had to find a way and we did. Looking back, we were the luckiest people in the world; there was no choice but to be pioneers.”

The source code for the moon control software has recently been published on github.

On a related, but less inspiring topic: boy’s club misogyny in computing. When I was looking for decorator images of Margaret Hamilton, I stumbled upon what appears to be an attempt to stuff image-search algorithms with “wicked witch” pictures.

I do not understand the haters. I’m fairly sure that none of them will ever accomplish a fraction, in their lives, of what Margaret Hamilton has done. Maybe that’s their problem.

WIRED: Her Code Got Humans On The Moon – and Invented Software Itself

Margaret Hamilton: Higher Order Software – A Methodology For Defining Software (Amazon)

Margaret Hamilton: Universal Systems Language for Preventative Systems Engineering

(* Feynman was generally critical about safety in most of the crucial systems of the space program in the 1980s; the only aspect where he seemed to approve was the flight control software – Margaret Hamilton’s legacy.)

(** In that sense, an operating system is just a form of code re-use.)

(*** This is a typical Hamiltonian play on words. “low level code” usually refers to assembler. “High-level languages” usually refers to a compiler/linker or interpreter/compiler that provides a more human-language-like interface to programming. Hamilton is implying that there is always a higher level of both maturity and abstraction.)

Every O/S Sucks, by Three Dead Trolls in a Baggie