In software development you’ll hear the term “moon shot”. If something is a “moon shot” it’s something that’s extraordinarily difficult, like landing on the moon. We say this about some app doing something cool, but what about the software that… landed us on the moon? What was the original “moon shot” all about?
The Software That Put Us on the Moon
Meet Margaret Hamilton. She was the director of Software engineering at MIT Instrumentation Laboratory, which was contracted to build the onboard software for the Apollo Space Program. This is her standing with the stack of source code used to launch us to the moon. Today we complain when Visual Studio runs slow.
If you’re a developer of any kind, you owe a lot of thanks to her, since “Software Engineer” wasn’t even a term before she came along.
So imagine having to write software that had to work the first time it ran, and run perfectly, or people would die. Sounds like a lot of pressure right? Margaret and her team did it. They built it, and it worked. It succeeded.
They made a piece of machinery land on the moon with a computer that had about .08 percent of the processing power of an iPhone.
You can get a lot more background and details here.
The Source Code
A few years ago, Ron Burkey released the source code for Apollo 11. He put a ton of work into this. This is the source code for the Apollo Guidance Computer, or AGC.
Not only can you download the source code, but he created a simulator for the AGC, at the Virtual AGC Page. You can dig deep into the systems and how they work, trust me it’s a rabbit hole for geeks. Tons of awesome stuff here. There’s even a kinder, gentler introduction to the AGC you can check out to get familiar.
The AGC source code is written in assembler, which is foreign to most of us. I’ve played around enough with x86 assembler to know it’s not my calling, but perusing through a lot of this source code, you can piece together how some of this stuff works.
Comanche and Luminary
If you dig into the code, you’ll see it’s divided into two parts, Comanche and Luminary.
Comanche is the software for the [Command Module](https://en.wikipedia.org/wiki/Apollo_command_and_service_module#Command_Module_(CM) and Luminary is the Lunar Module.
The Command Module was the cone that contained the crew and vital equipment, and was the vessel returned back to earth.
The Lunar Module well, it was the module that landed on the moon.
It’s very interesting to see how these systems interact. When you look through the source code you can see a lot of cool hints how everything works.
The DSKY was the user interface for the computer. You could enter commands through a calculator-like interface and it was connected directly to the AGC. The commands contained a verb and a noun for each command.
If you dig deep enough into the source code you’ll see a lot of references to the DSKY and commands related to it. It was a marvel of engineering for its time. Of course, there is a DSKY simulator if you want to play around.
How Do I Know so Much About This?
I may sound like a seasoned expert here, but I just took this free course on the code of the Apollo 11, then started digging in the code and researching stuff.
For the 50th anniversary of the Apollo 11 Moon Landing, Simon Allardice created this awesome course on Pluralsight exploring the AGC. It’s a quick course, and it won’t teach you how to write AGC specific assembler code, but it will give you a good idea of how things worked back then and how the whole thing fits together. After watching this you’ll get a better understanding of the source code, and start looking for easter eggs.
Ok if you’re a nerd like me, you love stuff like this. Obviously this isn’t some kind of actively developed code where you can do pull requests and add features. Nobody will hire you because you put AGC knowledge on your resume. But it sure is fun to go through this code and figure out how things worked, and look at the comical comments in the code. It’s fascinating and well worth the time to explore if you’re genuinely curious about this kind of stuff.
You can always yell at me on Twitter if you’d like to discuss it further.