The Limits of Melancholy

Of all the programming books you've never read that I've read more than once, The Limits of Software by Robert Britcher is my favorite. I say you've never read it with some confidence because a) few programmers read books and b) this book was doomed to a narrow audience by its very nature.

The first audience-limiting feature of the book is its style. As Robert Glass says in the Foreword, "It's part storytelling, part history, part art, part science, part philosophy, part logic--all entwined around the subject of computing and software." At the hub of it all is Britcher's experience with one of the largest engineering projects in history: the computer systems of the FAA. But that is only the hub, and the spokes are long and not straight or predictable. If you just want a straight story on his experience with the FAA Advanced Automation System, you can read Britcher's more ordinary recitation that appeared in the book Software Runaways. But this is more like sitting down to talk to someone who was in World War II--you don't get facts, figures, or dates like a textbook would give you, but you get stories that make you think, that you can find morals in, if you care to look for them.

The second audience-limiting feature of this book is that you kind of have to be an old programmer to appreciate it. For example, Ada is mostly just a name rather than a saga to a great many programmers who never knew a PC-less world. I remember when some distant cousin, being a military contractor, notified my parents that I should be learning Ada because it would soon be required of all programmers. I worried briefly, noticed that nobody else writing C code was worried, then forgot about it. Later, a small consulting company I was in got the job of helping port an Ada compiler to some Unix platforms. We marveled at the test suites it had to pass and wondered no more where our income tax money went. Much later, I briefly plunged into a real, honest-to-God Ada disaster as a sub-sub-sub-contractor on an anti-submarine aircraft software project for the military. The game, as it was explained to me by my elders on the project, was that everyone knew the project would fail, but we had better make damn sure that we were not the first sub-contractor to miss a milestone and get the blame for the true state of things. As I stared at hundreds of lines of paper Ada (there were not enough terminals for me to actually edit anything) and found that not a single identifier could be understood without first looking through reams of definitions and declarations elsewhere, I decided that this was the game Ada was born to play. I think it's hard to grasp lines like "Ada the language was eclipsed by Ada the cottage industry" if you never brushed up against it in your life.

More Than a Feeling

The thing that's unique to me about Britcher's book is that reading it leaves me with a powerful feeling. I get lots of things from programming books, but usually not an emotion. Oh, I did get a giddy feeling when I read Peopleware that the state of programming management was really going to improve. How embarrassing it is now to confess that I actually thought a book could make a dent in management behavior!

It took me a long time to put my finger on exactly what it was that The Limits of Software made me feel. Then I realized: it was melancholy. Melancholy is a hazard of age I conclude, now that my dotage is upon me. When you see email and instant messaging being invented again for the umpteenth time as though it were something new, or watch seven rounds of layoffs each be followed by hire-backs as management could never quite grasp that laying off N people reduces the head count by N+M (where M is the number of people deserting a sinking ship), melancholy is the natural response.

But the melancholy that Britcher instills is grander than I can convey here. The subject, after all, is about limitations, not abilities and accomplishments. If Isaac Newton saw further by standing on the shoulders of giants, Britcher sees further by standing on the piled corpses of our dreams. Dreams of bug-free code. Dreams that formalism and better processes will prevent software disasters. Dreams of "the right way" to develop software. Dreams of a better programming language that will remove our current dissatisfactions. Dreams that reusability will drastically lower development costs. Dreams that technology is the answer to human problems, and all shall be well, and all shall be well, and all manner of things shall be well.