Digital Apollo by David A. Mindell

If you're a space geek or a computer nerd you'll enjoy this historical account of the computers onboard the Apollo spacecraft, from laboratory schematics to the astronauts own words on piloting the lunar module during descent to the lunar surface. The account of Apollo 11's lunar landing and the piloting of Armstrong and Aldrin is as riveting as any action novel I've read.

From a historical standpoint, the insights into the development of "fly by wire" or computer control of the spacecraft are incredibly interesting. You've probably heard all the quotes about the quaintness of Apollo's computers and how your calculator has more computational power and memory.  But that's like mocking the Wright Brothers' first flight for not having beverage service.   Think about your desktop computer and whether you'd bet your life that it'll work perfectly for 2 weeks.  I'll just quote the author.

The space shuttle flies with five redundant computers.  Any fully digital airliner has a minimum of three.  Apollo had only one.  It never failed in flight.

Here's an interesting factoid.  Descent to the lunar surface began from an orbit of 50,000 feet.  That's higher than probably every jetliner I've ever flow on.  Why so high?  The uncertainty in the guidance up to the point of orbit insertion was about plus or minus 15,000 feet.  The the uncertainty of the known height of lunar surface features was 20,000 feet.  So 10 miles up seemed like a safe margin of error.

Computers on Apollo are primarily involved with guidance and control.  What's interesting is that the original contracts for development of the computers didn't even include time or budget for writing the software because the whole idea of software was so new in 1963 that no one thought much about it.  In the end, more people were working on the software than the hardware.

I won't even get into how the software was loaded onto Apollo's computers.  No punch cards.  No paper tape.  Rope.  Yes, rope.  You'll have to read the book to figure out that that means.

Mindell's Digital Apollo is subtitled Human and Machine in Spaceflight and beyond the history lesson there is a great deal of discussion about the tradeoffs of automation versus control and the role of the astronauts versus the spacecraft.  There's give and take here as noted in the following quote.

Real landings, with skilled but fallible people flying magnificent but imperfect machines in less than ideal circumstances, would begin to answer these questions.

The book was recommended to me by a friend (thanks, John) who thought I might be able to draw a parallel with my line of work: writing engineering software.  It too is imperfect and used by skilled people in less than ideal circumstances where there is a case to be made for automation.  But unlike the Apollo astronauts who constantly fought for and won the ability to actively pilot the spacecraft and preserve the deservedly proud tradition of test pilots in control of their machine, no one wants to "pilot" our engineering software.  Everyone would be thrilled if our software could run entirely automatically and completely hands-off.

Back to stories from the Apollo 11 spacecraft.  Many of you are probably familiar with the infamous "1202 alarm" that sounded repeatedly during descent that Armstrong struggled to work through as it distracted him from piloting the descent.  Engineers on the ground gave the "go" signal whenever it came up.  Turns out that the "1202 alarm" was something that many of us have probably included in our own software: "nobody thought they would ever occur in a real situation."  (We call this the "this will never happen" condition.)  Call this lesson #1 - things that should never happen occur more often than you think.  Then it was only through a partially unanticipated arrangement (the test configuration of the hardware didn't match the flight configuration) and partially unknown combination of events (a procedure was changed and turned on the altitude radar early) that the alarm occurred at all in the spacecraft.  Here's lesson #2 - it was a failure of communication - between hardware and software engineers, between procedure writers and programmers - that let this slip through.  Finally, "1202 alarm" was really not all that alarming.  All it meant was that the computer was so busy that it was dropping lower priority tasks as its very robust design was meant to do.  So lesson #3 could be one of user interface design - instead of an alarm the computer should have advised the pilot that the computer was too busy but critical systems were unaffected.

So Digital Apollo has it all - gripping narrative, historical insight, and lessons on computer-human interaction design.   Well worth it.