What Made Apollo’s 1969 Moon‑Landing Software So Remarkable?

On July 20, 1969, humanity set foot on the Moon, but few know that the navigation computer (AGC) was almost overloaded and repeatedly triggered the famous 1201 and 1202 alarms during the final descent.

If the computer hadn't recognized this problem and taken recovery action, I doubt if Apollo 11 would have been the successful Moon landing it was.

Margaret Hamilton, the lead of the software team, highlighted this in her own words. The overload was caused by the Rendezvous Radar continuously feeding data to the AGC, consuming about 15% of its processing time—data that should not have been present.

Because the AGC had to perform critical navigation and control calculations while also handling this extraneous input, its computational resources were nearly exhausted, leading to the alarms.

Hamilton’s team had designed the software with a priority‑scheduling mechanism: when resources were scarce, low‑priority tasks were voluntarily dropped, preserving enough CPU cycles for the high‑priority navigation tasks. This fault‑tolerant approach kept the essential calculations running and ultimately helped Apollo 11 land safely.

At the time, treating software as an engineering discipline was revolutionary. Hamilton coined the term “Software Engineering” to stress that rigorous engineering methods were needed, even though many then dismissed the idea as a joke.

The AGC hardware weighed about 32 kg, ran at roughly 2 MHz, and had only 2 K words of RAM (≈4 KB) and 36 K words of ROM (≈72 KB). By contrast, a single modern smartphone photo can exceed the entire memory of the Apollo computer.

The source code, stored on paper, was written in the AGC’s own assembly language, a language unlike today’s x86 or ARM assembly because the AGC used a completely different CPU architecture.

CA      Q
TS      L
INDEX   A
TC      BANKCALL

Developers of the era lacked modern tools such as VSCode, IntelliJ IDEA, GitHub, Git, SVN, or automated code‑review systems. Paper served as the code repository, and any change required printing the entire source, manually editing on paper, discussing the modifications, and obtaining engineer signatures, audits, and re‑entry into the computer.

Print full source code

Edit on paper

Discuss on paper

Perform code review

Conduct design review

Software changes also demanded engineer signatures, formal reviews, and re‑loading into the computer, making extensive paper archives normal.

The final program was loaded into Core Rope Memory, where wires were literally woven: a wire passing through a core represented a binary 1, while a wire looping around represented a binary 0. As a result, Apollo’s ROM was “woven” rather than compiled.

Apollo’s ROM wasn’t compiled; it was "woven".

In summary, while today we take multi‑core CPUs, gigabytes of memory, cloud computing, and automated deployment for granted, the 1969 Moon landing succeeded with a 32‑kg computer, a few kilobytes of memory, and a team that anticipated how to keep a program running after errors occurred. This elegant handling of exceptions under extreme resource constraints still exemplifies great software engineering.