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 founded her work, reporting 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.
• named domain patterns with attached rules, which Rust calls typestate 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 here.

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 the realm of requirements engineering, or what is now called AI alignment and 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 missing

Hamilton has nothing to say about vertical intent, although 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.

In detail: Hamilton’s 001 tool suite

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 the HP 700 series, the IBM RS/6000, SunOS and Solaris, and Digital’s Alpha Unix, with about seven million generated lines across versions. 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.) 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. The big claim was that one systems language and one suite could carry intent from requirements through to running software.

Today we have some of the answers to the questions Hamilton was asking in 1994. A lot of the pieces became everyday and expected over time. Today we see VS Code extensions which let developers reshape their working environment. OpenAPI and protobuf generate client and server code from specifications. Simulink and SCADE let safety-critical engineers simulate models and generate code, while GitHub Actions and similar systems connect source, tests and deployment.

The idea of testing code has, evidently, survived althogh Hamilton’s closing paragraphs posits that verification will become an obsolete process and that testing tools would no longer be needed because most errors would cease to exist! Generated systems still need trusted generators, verified compilers, fuzzing, property tests, model checking and production monitoring. The June article deepens the point about horizontal intent: Hamilton understood the need to connect intention to implementation better than almost anyone, and much of the field moved in her direction without adopting the 001 Tool Suite itself.