From Moon Landings to Modern Software
From Moon Landings to Modern Software
Complicated Software Lessons from the Apollo Guidance Program
Modern software systems make change difficult. However, before we can address complex software, we first need to distinguish it from software that is complicated. In this Better Bits excerpt, I retell the story of one of the OG’s of software engineering, Margaret Hamilton. Enjoy!
Developing quality software has always been challenging. That does double for software to send people to other celestial bodies safely. The Apollo guidance system was (and, frankly, still is) a wonder of modern software development. A team of 350 people, led by Margaret Hamilton, spent 1400 person-years through much of the 1960s crafting the bits necessary to land astronauts on the moon. And, just as importantly, bring them back.
The Apollo guidance system was complicated. The software needed to work exactly how it was expected to, without deviation, repeatedly regardless of circumstances -even when the data provided to it was unexpected.
In addition to leading the software team, Margaret was also a working parent. Her daughter, Lauren, often accompanied Margaret to work. While there, Margaret would run tests, and Lauren would pretend to be an astronaut.
During one of these test sessions, Lauren entered something unexpected. The guidance computer immediately crashed, which subsequently brought the whole system down. Upon investigation, Margaret found that Lauren had inadvertently loaded a pre-launch program, called P01, while the command module was in flight. The results would be disastrous if an astronaut did this during a mission.
To prevent this from happening, Margaret suggested adding additional software checks to the codebase. However, NASA denied her request because storage capacity was already in short supply (the Apollo spacecraft only had 4KB of RAM, and a 32KB storage capacity). Furthermore, more code meant potentially more bugs. Finally, NASA felt that a real astronaut couldn’t possibly load the pre-launch program while the mission was underway.
In a notable, early example of “fixing it in documentation”, NASA added a user note to the manual: “Do not select P01 during flight”. Despite the warning, Astronaut Jim Lovell accidentally loaded the pre-launch program on the 5th day of the Apollo 8 mission. As seen during testing, the system crashed.
Thankfully, Margaret scrambled her team and, after a furious eight hours, they were able to engineer a recovery method. People would have died without their quick actions and considerable expertise.
Much of the software created before, during, and since the Apollo guidance computer has remained complicated. Complicated software is self-contained; while it might process data from the external environment, the entirety of the code was produced by the same team working toward the same outcome: safely deliver humans from the earth to the moon and back again. As shown in the case of Lauren and Jim’s miss-entries, complicated software behaves the same way when given the same data.
This standardized, predictable outcome is a good thing in many cases. In a complicated software system, imprecision is diminished, and non-objectivity and uncertainty are reduced as far as possible. In complicated systems, behavior is explained by obvious chains of cause-and-effect. Software with these properties remains valuable. After all, it would be very bad if the software responsible for your commercial flight began exhibiting emergent behaviors.
Because of these properties, complicated software systems are also externally controllable. A bright individual or dedicated team, like Margaret’s, can identify the source of a problem, craft a solution, and be reasonably assured that things will now work as intended. That doesn’t mean complicated software is easy; putting one foot before another may be easy to understand, but running a marathon still remains quite challenging.
Complicated software is all around us. However, more often than not, what we build today is complex.
If you enjoyed this excerpt and want updates on how the book is progressing, be sure to subscribe.
Next time: Why We Can’t Stop Building Complex Software