Ever play Lunar Lander as a kid? Now you can build your own.
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.
This isn’t the first time that software associated with the space program has been released to the open source community. This particular program had even been released before, in 2003, by tech researcher Ron Burkey, writes Keith Collins in Quartz. In fact, he transcribed it from scanned images of the original hardcopies MIT had put online by manually typing each line. Moreover, he even had to reconstruct some unreadable parts.
But by being posted to GitHub, the code is now getting a lot more attention.
You might think that software that old, for a rocket that no longer flies, in a language hardly anyone ever uses, would be nothing more than a museum piece. (Even if NASA had to coax a 77-year-old programmer out of retirement a few years back to modify some code on Pioneer.) But it turns out that it’s offering us some valuable lessons.
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.
2. Women programmers had a big role. Making the code more widely available brought new attention to Margaret Hamilton, director of software engineering for the project. In particular, there’s the seminal picture of her—in mid-1960s garb—photographed next to a stack of code printouts as tall as she was. While the stereotype of the time was that programmers, particularly NASA ones, were men, women obviously played an important role. (Incidentally, Hamilton—who is credited with coming up with the concept of “software engineer,” is still alive at 80, after serving as CEO for several startups following her MIT career.)
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.”
“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.
Simplicity 2.0 is where we examine the intricate and transitory world of technology—through a Laserfiche lens. By keeping an eye on larger trends, we aim to make software that’s relevant to modern day workers, rather than build technology for technology’s sake.
Subscribe to Simplicity 2.0 and follow us on Twitter. If what we’re saying piques your interest, head over to Laserfiche.com where you’ll see how we apply the lessons learned on Simplicity 2.0 to our own processes, products and industry.