Preface

As a high school student in the late 1970s, I wrote an article for the school newspaper explaining what a personal computer could do. Among its other virtues, it could store recipes. That wasn’t wrong—it just doesn’t seem like the first thing you’d choose to say about a modern computer.

Back in those days, it was easy to perceive that something important was happening, but we couldn’t quite see all the way to today’s capabilities. Since we now have an abundance of devices and services using computers and communications, there is no longer any need to argue for the value of computers. Indeed, the challenge now is getting people to disconnect from their mobile phones, tablets, music players, and laptops long enough to discuss the merits of something else.

Alongside the evolution of computers from bizarre novelty to ubiquitous necessity, there’s been a substantial amount of discovery and invention. In roughly the same way that it was once useful to explain what computers were, I think it’s now useful to explain something about the larger context of computer systems and infrastructure.

In everyday life, plumbing is tremendously important but little noticed until it goes wrong—and likewise computational infrastructure. You most likely don’t care much about the pipes in your house unless one of them springs a leak or otherwise fails, in which case you develop a strong need for someone to fix it immediately (and are willing to pay them well to do so). Being a “computational plumber” is likewise a good but generally unglamorous life. I have had the good fortune to examine a cross-section of the world’s major organizations, where I have seen some of the good, bad, and ugly of what they do with their infrastructure.

It is strange to observe that it is easier for a nonspecialist to learn what physicists know about special relativity than to learn what computer scientists know about coordinating processes—even though almost nothing of daily life has any connection to special relativity, while almost all of our daily activities involve some amount of coordination among processes. I’ve seen that there is too little awareness of the “big ideas” of computer science in places like the New York Review of Books or National Public Radio, where they could and should be relevant.

Accordingly, this book explains computer systems to people whose intellectual interests are firmly rooted elsewhere—particularly in the humanities. Although my own university education has all been in engineering, I am a supporter of both liberal arts and informed citizens. I see knowledge as crucial for our intellectual and political freedom, as well as the realization of our human potential.

The book deliberately avoids programming. My empirical observation is that there are intelligent, educated people who simply don’t like programming. I think this claim is readily verifiable and quite understandable: programming is actually quite a strange activity, but those of us who have learned to program tend to forget its strangeness. An unwillingness or lack of interest in programming strikes me as comparable to a lack of interest in opera: it does imply that some arguably important knowledge and experience will remain out of reach, but does not imply that the “non–opera person” needs remedial help.

How can we structure an exploration of computer science ideas where programming is not used? The goal is not to provide a complete introduction for future professionals, but rather to hit highlights for the curious. My organizing principle is analogous to a zoo. There are some collected specimens, and I will both describe the individual “animals” and point out some of the connections among them.

Zoos are out of fashion today. Better to see animals in their natural habitat, or failing that to see them in sprawling parks that better simulate their natural habitat. Certainly if we have a choice, it seems wise to prefer a presentation that is less artificial, less constrained, more like the real world of the animals on display. And yet the old-fashioned zoo with its caged animals played an important educational role of showing real animals from far corners of the world, and starting to create a consciousness of their significance. The zoo was an important bridge between the animals in the wild and a broader human appreciation of their importance.

My zoo contains some technical issues that may well be unfamiliar even to people who are computer professionals. Writing the book was an interesting learning experience, as I repeatedly challenged myself to explain what really matters, and why it matters, without falling back on some version of the generic accepted curriculum for computer science. Some readers may gain helpful insights from reading the book, while some readers may be deeply annoyed. It’s even possible that the same reader may have both kinds of experiences.

As with any zoo, reasonable people can find fault with the completeness or coherence of the collection I present. As with any zookeeper, I will explain my choices by pointing to a combination of intent and circumstances. A notable influence is the magisterial textbook Principles of Computer Systems Design by my colleagues Jerry Saltzer and Frans Kaashoek. Indeed, you can think of this book as the nonprofessional’s gloss on what professionals learn from that text. If you are interested in pursuing these topics further, it’s an excellent resource.

Completing a tour of this zoo doesn’t make anyone into a professional programmer, or even necessarily give a complete introduction to any of the topics—just as a visit to an animal zoo doesn’t make anyone into a zoologist, or even provide a complete view of any single animal. But in both cases we can get an appreciation of some of the individual characteristics and also start to form an impression of the wonders of the interconnected world that contains such individuals.