NASA’s Apollo 11 mission—the mission that put human beings on the moon for the first time—was launched in 1969, the year after I was born. My early Christmas presents were giant kids’ books full of pictures of that giant Saturn V rocket launching into space, the command and lunar modules, and of guys in bulky space suits walking on the moon. The first intelligible answer I gave to the question, “What do you want to be when you grow up?” was, “Astronaut.”
I did not end up becoming an astronaut.
Computers also captured my attention at an early age, and now I work as a developer for Slate. But my fascination with space endures—so needless to say, I was pretty excited when I heard that the source code for Apollo 11’s computer guidance systems was uploaded on July 8 to Github, a popular site used by programmers to share code and collaboratively build software. Anyone can now read the actual lines of programming code used to land men on the moon.
The code was written in the late ’60s by Margaret Hamilton and her team at the Massachusetts Institute of Technology Instrumentation Laboratory for the Apollo Guidance Computer. The code is pretty inscrutable to casual inspection: It’s not written in a programming language recognizable to modern coders. But Hamilton and her team wrote comments in their code (just like I do when I write code for Slate’s website) to help remind them what’s going on in a given spot in the program. Those parts are surprisingly readable. Here’s a block of code from a file called BURN_BABY_BURN–MASTER_IGNITION_ROUTINE.s (really, that’s what it’s called):
So, clearly, “don’t forget to clean out leftover DVTOTAL data when GROUP 4 RESTARTS and then BURN, BABY!” I have no idea what a DVTOTAL is, but I’m pretty sure that by BURNBABY, they mean “launch a 300-foot rocket ship into space.” And how totally and completely freaking awesome is that?
Altogether, with comments and some added copyright headers, the AGC code adds up to about 2 megabytes—a teeny tiny fraction of the amount of code packed into an Apple Watch. You probably downloaded more data in the process of loading this web page. That’s perhaps not surprising, given the limitations of the equipment the code ran on. The Apollo Guidance Computer was miraculously advanced for the late 1960s, able to be used on a very power-, space-, and weight-constrained space ship. Still, it could only run a couple of kilobytes of code at a time.
But what is surprising (and wonderful) about this pile of code is the human-ness shining through. They may have been rocket scientists, but at least one of the coders had a terrible habit of typing “WTIH” instead of “WITH” (like 20 times). And here, reading this block of code inLUNAR_LANDING_GUIDANCE_EQUATIONS.s, it’s not hard to picture a young MIT engineer writing code while imagining landing on the moon:
Under the right circumstances, the AGC could halt and abort operations without dumping memory, forcing the computer into Program 00, a condition called a “P00DOO abort.” Scattered throughout the comments are references to this condition where it’s typed out as “POODOO” (O’s and not zeroes), so it’s pretty clear how they pronounced it when discussing it aloud. There’s no question in my mind that 30 years before anyone had heard of Jar-Jar Binks, NASA engineers stood around chalk boards discussing how to prevent their programs from taking a poodoo.
When the AGC and the software that made it work were created, there was no Github, no Stack Overflow, no widely used and tested software design principles to follow. Everything these engineers did had to be imagined, built, tested, fixed, retested, reimagined, and tested again from scratch. With each and every instruction they wrote, it could never have been far from their minds that if this instruction fired as planned, humans would walk the moon for the first time. And if it failed, astronauts could lose their lives.
During the actual Apollo 11 mission, an unlikely set of circumstances caused the guidance computer to begin throwing alarms just three minutes before the lunar module was to land on the surface. A problem in the radar system used to recapture the landing module in the case of an abort caused its AGC program to start using more computing cycles than it was supposed to—at the very moment when another program, the one that was helping land the craft on the moon, was in its most critical phase. It was the robustness of the software design, which included routines to ensure that higher-priority instructions were executed over lower-priority ones, that allowed the AGC to continue working, thus ensuring that Apollo 11 could continue on to successfully land on the moon.
When I was a kid, I was inspired by the temerity and courage of astronauts walking on the surface of the moon. Now that I’m an aging computer nerd (and not an astronaut), looking at this code has reminded me that the magnitude of its technical and engineering achievement can’t be overstated. It’s thrilling to see the work of computer nerds who made typos and dumb jokes, who couldn’t really know that what they were doing would work—and who showed that there’s no limit to what people can do with enough brainpower and really hard work.
