Introduction

YAUB (Yet Another Unfocused Blog)

This title may sound pompus, or boring. I thought is sounded like some sort of boring textbook from high school. It's a thin book, so it's a wonder I ever noticed it browsing the Seattle Public Library Shelves. For whatever reason, I browsed the book, read a few paragraphs, and realized that it was well written, and it concerned an interesting topic.

This book is an example of "creative nonfiction". At least that is what the author has called it, though he doesn't seem terribly comfortable with the label. The book has stories, mostly about programmers, their supervisors, their supervisors' supervisors, and a wife and a few non-programmers. The thing bringing all these folks together was the FAA and it's making of an air traffic control system in the sixties and seventies, and the failed attempt to update this system -- I should say overhaul the system -- in the eighties and the nineties. I remember talk on CNN about some sort of new system to replace the decades old air traffic computer system. I didn't realize it was IBM's biggest contract. The overhaul failed, and I didn't notice the newscoverage.

Though this is a small book, I fear summerizing it's concepts. I don't want someone to read my review and think, "Oh, I get it." and decide they shouldn't actually bother reading the book. To avoid this, I am going to mention that I'm giving my interpretation of Bricher's book, and you better read it yourself unless you want to just let my baised view take over.

When somebody wants to build something really big, like a 100 story building, or a bridge across the Staights of Gibralter, people will pause and wonder if it is a reasonable thing to do. Can something so complicated work? Can something so large stand? Will it be so big that it will only be in the way? Is it needed or wanted? Because software is not quite physical, and because most people have really very little understanding of programming, really big programming challenges do not create the same sort of skepticism and worry of big physical projects associated with engineering. Actually, the attitude is often just the opposite, and people are easily convinced that if large systems are not controlled my new and state of the art computer systems, your are behind the times and vurnerable to human error and poor efficiency.

In the 1960's the 9020 System was used to automate the air traffic control system of America. The programming was done mostly is assembly code. It was done using punch cards filled in by hand, punched by specially trained techs, and delivered by couriers to the computers themselves. It was slow to get your programmed entered, so the programmers debugged with paranoid fervor. The reward for all this tedium was a system that worked. Actually, it's still working.

You might think that the main idea was that his old fashioned programming style was the key to the success of this project from decades ago, and the failure of the new system, the AAS, the Advanced Automated System, was due to new programming techniques likes OOP and IDE's. It's not so simple. Or maybe it's simpler. The biggest reason that the AAS didn't work was that is was such a huge project. New programming styles, and software engineering managment is questioned and criticized, but ultimately Britcher is sympathetic to the people who worked on the massive undertaking.

The author lets his stories express his opinions, and avoids creating a heavy handed rant against software trends he dislikes. At the end of the book Britcher explicitly tells the reader what he thinks will improve the programming world. Program carefully all the time seems to be one of the themes. Consider if you want to make the program. Maybe you don't really need it. Code with care and keep the testing systems under pressure to find errors, and not just to rush code into an "approved" status. The author writes, "Commercial software should be guarenteed and warrantied and certified in a manner similiar to the drug trials conducted by the Federal Drug Administration and, in the case of physical artifacts, by the Underwriters Laboratory.

Agree with him or not, the stories of the stress and strain of working on computer systems, makes for facinating stories. Programmers and managers are put in near impossible situations and results (neurosis) can be very touching. I wonder if "certified" software will ever become common? Stranger things have happened.