We use cookies and other tracking technologies to support site functionality, remember preferences, protect against fraud, and analyze traffic. With your consent, we also utilize advertising cookies and other tracking technologies to provide you with personalized ads. By clicking Yes, you consent for us to set advertising cookies. Please see our Privacy Policy.

3 Things to Learn From Apollo Lunar Module Code

The Apollo Guidance Computer (AGC) software that took the Apollo 11 mission to the moon, developed by the Massachusetts Institute of Technology’s Instrumentation Laboratory in the mid-1960s, has been published to the open source repository GitHub.

1. Comments are important. As soon as the code went up on GitHub, people immediately started scanning the comments—if only because many of them couldn’t necessarily understand the ancient Assembly language in which the code was written. And what they found charmed them.

Not only was the code well commented, but the programmers showed evidence of having a sense of humor, with comments such as “TEMPORARY I HOPE HOPE HOPE” and calling the ignition subroutine BURN_BABY_BURN after the catch phrase of an early 1960s disk jockey who was popular during that era.

“In other words, one coder was warning others not to bash or make fun of his code.” Noted one reddit commenter, “It’s humbling to see that the folks who wrote the code that took us to the moon are basically just like me and my coworkers.”

The lesson here? Write your comments carefully. People may still be reading them half a century later.

And if you’re interested in learning more about the role of women in the space program, the upcoming movie Hidden Figures, slated to come out for general release in January, is all about the pivotal role female African-American mathematicians played in the early Mercury and Apollo programs.

The lesson here? We hope nobody reading this needs to be reminded of the value in hiring women, as well as minorities, the disabled, seniors, and other groups, for technical projects.

3. Never assume that a user won’t do something. When Hamilton’s four-year-old daughter Lauren was playing with the simulator, Hamilton found she could crash the simulator by starting another program while the simulator was in flight. “Hamilton wanted to add code to prevent the crash. That idea was overruled by NASA,” writes Robert McMillan in Wired. “We had been told many times that astronauts would not make any mistakes,” she told him. “They were trained to be perfect.”

Guess what.

“Right around Christmas 1968—five days into the historic Apollo 8 flight, which brought astronauts to the moon for the first-ever manned orbit—the astronaut Jim Lovell inadvertently selected P01 during flight,” McMillan writes. The result? It wiped out all the navigation data that would help the AGC figure out how to get the astronauts home. “After spending nine hours poring through the 8-inch-thick program listing on the table in front of them, they had a plan. Houston would upload new navigational data. Everything was going to be OK. Thanks to Hamilton—and Lauren—the Apollo astronauts came home.”

The lesson here? When designing for users, design as if the product will be used by a four-year-old. After all, even rocket scientists make mistakes.