In responding to a recent security problem I had to consider the idea of intent in computer software, so I looked to see what Margaret Hamilton ↗ has to say. Hamilton proved her ideas spectacularly during the first Apollo moon landing in 1969. A hardware failure generated unexpected errors ↗, but the software coped by running the highest-priority tasks despite the barrage of errors, preventing an abort seconds before landing on the surface. The abort procedure was dangerous, so she may have prevented tragedy in multiple ways.

Hamilton’s observations on reliable and secure systems remain highly relevant. Despite spending four decades telling the world how to make reliable software very few people have put her ideas into practice, and fewer in the integrated manner she promoted.

Margaret Hamilton at the Apollo command module simulator
Margaret Hamilton at the Apollo command module simulator. Image courtesy MIT Museum (GCP-00009683).
Cover of Electronic Design Software Engineering Supplement, 4 April 1994
Electronic Design Software Engineering Supplement, 4 April 1994. Click to read the reconstructed PDF.

I eventually found two 1994 articles by Hamilton in Electronic Design magazine ↗: one explaining her Development Before the Fact philosophy, and one describing the software lifecycle tools built from it. After discussion with the current magazine editor, I was able to clean up the scanned text of the paper copies and document Hamilton’s prescience.

Hamilton’s vision

Hamilton’s Apollo experience formed her work, and she reported that interface errors accounted for about 75% of all defects found in the flight software during final testing, and that she invented Development Before The Fact to eliminate that entire class.

In the article explaining her vision, Hamilton describes a system design language built around behaviour in time and space: FMaps for what a system does over time, TMaps for the data and objects it acts on. The piece reads to 2026 eyes as though it describes:

  • algebraic data types, what we call generics in Rust, Haskell, OCaml and TypeScript.
  • constraints as first-class citizens of the language, with niche implementations in Liquid Haskell, F* and a few others. But mostly its just a theoretical notion.
  • named domain patterns with attached rules, which Rust calls typestate (or so it seems to me; if you’re a deep language expert please do send in corrections!) and which appear in the literature as session-types.
  • runtime instances typed by static structure, which seems to be pretty close to formal verification methods now used by many organisations ↗ but few overall
  • end-to-end object traceability, where any specification, bug or feature can be followed through its implementation and execution

In the decades since, we have seen slow progress in implementing parts of this vision here and there, but nothing integrated in the way she advocated. Hamilton published a companion article ten weeks later describing the 001 Tool Suite, her commercial environment intended to implement Development Before The Fact in practice. That article is also reconstructed below.

Different kinds of intent

If we divide intent into two kinds, we can see Hamilton and just about everyone else focusses on only one of them:

Horizontal intent is the question Margaret Hamilton asked: “does what we say in code match what we actually wanted?” This is requirements engineering, or what is now called AI alignment and its mirror, specification gaming.

Vertical intent is the question that very few focus on, that of whether what we say in code is faithfully transmitted by the toolchain down to the running silicon. This is Ken Thompson’s Reflections on Trusting Trust ↗, and the xz supply chain incident ↗, and is what I was looking for.

Vertical intent checking is generally missing

Hamilton has nothing to say about vertical intent. Some aspects of reproducible builds ↗, diverse double-compiling and a few niche technologies do address it. The idea of the Trusted Computing Base (TCB) is an important starting point, where we establish the correctness of the set of hardware, firmware, compilers, libraries etc before we can make any promises about how a piece of software will run. But the community that works on these topics seem quite far removed from the everyday tools that need to be made reliable. Most engineers have little idea what is in their own toolchain’s TCB, and do not have integrity checking in place in this vertical sense. Reproducible builds are becoming more common and that helps, but it seems ‘intent’ in this sense is not well-addressed.

And so I discovered that even Margaret Hamilton couldn’t help with this particular kind of software integrity. Neverthless, it was very rewarding to discover in detail what she got right decades ago, often in advance of practice today.

Margaret Hamilton at the Intrepid Museum, 2019
Margaret Hamilton at the Intrepid Museum, 2019.

In detail: Hamilton’s 001 tool suite

Cover of Electronic Design Software Engineering Supplement, 13 June 1994
Electronic Design Software Engineering Supplement, 13 June 1994. Click to read the reconstructed PDF.

Hamilton’s June 1994 article, 001: A Full Life Cycle Systems Engineering and Software Development Environment, shows what Hamilton Technologies built around her theory. Development Before The Fact was meant to prevent errors by making the system definition strong enough to rule out bad designs. The 001 Tool Suite covered requirements, design, generated code, simulation, documentation and project management. In modern terms, Hamilton was describing an integrated development environment where requirements, types, execution, testing and builds all knew about each other.

Hamilton reported that the 001 suite generated itself just like we often see in a modern toolset: about 800,000 lines of code per platform across ancient computers still seen supported by NetBSD and other open source operating systems such as HP 700, the IBM RS/6000, SunOS and Solaris. She claimed productivity improvements from 10:1 to 100:1 over traditional C development, and that the ratio rose with the size of the system “because reuse compounds” (that is one of her claims that has not aged so well, and would not be made today.) The National Test Bed put that to an independent test, giving the same real-time distributed problem to three contractor teams under then-current 2167A software development rules ↗. Of the three, only the 001 team generated fully production-ready code, running in both C and Ada from one definition. Her big claim was about what I’m calling horizontal intent, that one systems language and one suite correctly conveys intentions from requirements through to running software.

Today we have some of the answers to the questions Hamilton was asking in 1994, for example:

  • Extensions in NeoVim, Emacs, Pi and VS Code let developers reshape their working environment.
  • protobuf and many LLMs will generate client and server code from specifications.
  • Simulink and SCADE let safety-critical engineers simulate models and generate code.
  • Continuous Integration systems such as Woodpecker, GitHub Actions and so on connect source, tests and deployment.

Hamilton’s closing paragraphs didn’t work out… she posits that verification will become an obsolete process and that testing tools would no longer be needed because most errors would cease to exist! We now know that generated systems of all kinds including AI still need trusted generators, verified compilers, fuzzing, property tests, model checking and production monitoring. The June followup article explains more about horizontal intent.

Margaret Hamilton helped change the field of software development, showing by example what is important. Her tools were not adopted but her thinking, while radical for the time, is mostly considered best practice. I do wonder if we would be using her 001 Tool Suite today if she had published the source code.