X
More Topics

Apollo's lunar lessons for IT

The 40th anniversary of the Apollo 11 moon landing has concentrated on heroics, politics and mechanics. Apollo 11's computer has its own secrets
Written by Leader , Contributor

It was the most famous error message in history.

As Armstrong steered the LEM lunar lander towards the Sea of Tranquility, the ship's guidance computer did what IT on any planet does best. It chose the worst possible moment to go wrong. "Alarm," it said. "1201."

That code hadn't come up in any simulation, and the astronauts had no idea what it meant. It could signal the end of the mission — or worse. "Get us a reading on that 1201 alarm," Armstrong requested, in the manner of a chap who really didn't have time for that right now.

It would be nice to say that 40 years on, we have left such unpleasant and incomprehensible surprises behind us. We have not. Those who habitually listen to Mission Control's radio conversations with the International Space Station will know how much time is taken dealing with Outlook errors, and those of us with more earthly concerns are no strangers to messages that say: 'Something has gone wrong and you need to do something about it,' and not an iota more. And where's the button next to the error message that says "Google for this"?

Apollo had an excuse. With 32k of memory, around 10,000 transistors and a clock speed of a few hundred kilohertz, it had little time or room for niceties. The superb programming of the system meant the alarm, caused by the rendezvous radar being unexpectedly active, didn't cause the loss of any critical processes. These days, we've lost the hardware restrictions but also the habit of superb programming. That's hard to call an advance.

The lessons of the 1201 alarm are many. Design defensively, assuming that things will go wrong: even with the most intensive testing and simulation programme imaginable, reality provides the unforeseen, as reality is wont to do. Test what you fly, and fly what you test: the back-room experts who diagnosed the 1201 and decided to continue the mission did so because they knew exactly what was being used in the LEM. QA and bug testing becomes increasingly useless as systems diverge. Accurate documentation can save your skin. To be useful, an error message must lead directly to an explanation and suggested course of action, whether via Houston or Google.

It's a cliché to say: "We got men to the moon, but we can't make our email work.". It's true, nonetheless. The art of getting to the moon may not have advanced since 1969, for many good reasons. The art of the error message has no such excuse.

Editorial standards