The Limits of Software and the Advanced Automation System (AAS)

Finished reading "The Limits of Software: People, Projects, and Perspectives", by Robert Britcher. This was really an interesting book from a geek perspective and will probably end up as my second favorite book about software projects, along with Frederick Brooks' The Mythical Man-Month.

It was recommended in Don Brown's excellent blog Get The Flick, in separate posts here, here, here, here, and here.

The author describes major programming efforts he was involved in at IBM, starting with the Cold War's SAGE command-and-control system and the Apollo space program, moving into aviation with the 9020 Host and later the ARTS tracking system, and ending with the ill-fated Advanced Automation System (AAS), which was supposed to overhaul the national air traffic control system and ended up being both (1) the most expensive software project ever undertaken and (2) a debacle that all participants agreed to walk away from. One participant said, "It {AAS} may have been the greatest failure in the history of organized work."

Let me quote a brief description of the AAS snafu from the book:

One engineer I know described the AAS this way. You’re living in a modest house and you see the refrgerator going. The ice sometimes melts, and the door isn’t flush, and the repairman comes out, it seems, once a month. And now you notice it’s bulky and doesn’t save energy, and you’ve seen the new ones at Sears. So it’s time.

The first thing you do is look into some land a couple of states over and think about a new house. Then you get I.M. Pei and some of the other great architects and hold a design run-off. This takes awhile, so you have to put up with the fridge, which is now making a buzzing noise that keeps you awake at night. You look at several plans and even build a prototype or two.

Time goes on and you finally choose a design. There is a big bash before building starts. Then you build. And build. The celebrating continues; each brick thrills. Then you change your mind. You really wanted a Japanese house with redwood floors and a formal garden. So you start to re-engineer what you have. Move a few bricks and some sod. Finally, you have something that looks pretty good.

Then, one night, you go to bed and notice the buzzing in the refrigerator is gone. Something’s wrong. The silence keeps you awake. You’ve spent too much money! You don’t really want to move! And now you find out the kids don’t like the new house. In fact, your daughter says “I hate it”. So you cut your losses. Fifteen years and few billion dollars later, the old refridgerator is still running. Somehow.

I was predisposed to like this book for a few reasons: I think we fail to appreciate that there's very little new under the sun (VLNUS) and we fail to recognize that great strides were made in both programming and the art of software projects in the 1950's and 1960's. It didn't start with Bill Gates, Steve Jobs, or Tim Berners-Lee; they were late to the scene, and they stood on the shoulders of giants.

In The Limits of Software, the author tells the story of the early integrated systems of computers. Where Brooks wrote about the technical aspects of managing software projects, Britcher writes more about the artistic and cultural aspects, and the nature of programming itself (for instance: it's not a science). He says the secret to managing software projects is to "Superimpose onto the business of symbol writing the management practices of classic production, but allow for the eccentricities of the symbol writers." There are volumes of wisdom in that sentence that probably apply beyond the realm of software projects.

Britcher returns again and again to the importance of thorough and disciplined testing, and bemoans the absence of testing in modern software due to the eagerness to ship the product and the lack of familiarity with rigorous processes. He says he can easily tell which projects will definitely succeed and which will fail; projects that spend 60% of their budget on testing will succeed.

The technical approach used in the Advanced Automation System played a large part in its demise. The emphasis on programming in Ada seems indefensible in retrospect, but at the time it had all the buzz as the next great language and Ada eventually found a place in many critical DOD systems. Unfortunately, the AAS was an early adopter (if not the first adopter) of Ada, and the project bore an expensive learning curve.

Poorly defined requirements, scope creep, and the lack of a testing regime stacked the deck against AAS. The final fatal flaw was the immense funding stream in the hands of outsourced contractors who were paid for their time and not for results. The Beltway Bandits are willing to gorge at the trough even in a doomed project; the money is too good to interrupt the dance. The government contracts from AAS moved from away from IBM and into LORAL, which was then purchased by Lockheed Martin.

The features and business described in the Advanced Automation System did not die. The display work morphed into Sector Suites and Lockheed-Martin's DSR (Display System Replacement) program in the Enroute world, and into Raytheon's STARS program in the Terminal world. The drive for a "paperless" system (no printers) became Mitre's URET. IBM's 9020/Host automation replacement effort was reborn as Lockheed-Martin's ERAM, which may still not be immune to the issues that affected AAS.

Finally, the book seems to present an informed prelude to the impending multi-billion-dollar investment in the NextGen system, and so I hope the future architects take the time to study Britcher's book.

I think this would be an interesting read for those interested in software development, large-scale project management, or aviation automation.