While a program expresses intent, it is the computer, the hardware, that brings that intent to life. In order to have full control over your program’s expression you must control the computer that runs it. Therefore: Write your program for a computer with a plug. Should you be dissatisfied with the behavior of the computer, unplug it.

I’m working from memory here. This idea, the idea that you could unplug a computer, is an idea that has run in and out of our culture for about as long as there have been computers. I’ve expressed the idea as a pattern, a problem and its solution. I’m thinking about this pattern because it reminds me of programming with Kent.

I haven’t got the words to this pattern quite right. It gives the impression that I fear computers run amuck. Does anybody remember that old film, the Forbin Project, where the US defense computer gets to talking to the Soviet defense computer and they get the idea that they can run the world better than us? Well, that’s not the problem.

I first wrote the "don’t program a computer you can’t unplug" pattern because Kent and I needed a pattern at a large scale. We were looking for big advice for a new kind of developer. We imagined ordinary people taking their computing needs into their own hands. These people would use powerful languages to express themselves. But they would also need clear advice about using them. The "unplug" pattern says, before you start writing a program, get a computer that you can control for your own purposes. It says: Don’t settle for a computer in a glass room. Don’t borrow time. Get your own computer. Make it yours.

There is a lot of history to this pattern. Kent and I shared a vision of computing. We worked in a lab that used the sandbox approach to research. You know, give all the researchers the kind of computer that will be the norm in a decade and see what happens. We had dual-processor workstations with huge screens and graphics accelerators on every desk. And what happened? Not too much. For some reason most people thought they needed permission to write programs. Not us. We made those machines our own.

We wrote programs together for a year and a half. We’d make up a problem over coffee on Monday, have a prototype struggling by Tuesday, and be dragging people into the office to see results by Friday. Yes, it was like that, except when it wasn’t. Sometimes we’d get stuck. By Tuesday we would be over our heads and out of ideas. We had a program going nowhere. So we pulled the plug.

Kent and I could walk away from an undone program. We could because we were writing those programs for ourselves. We had no further use for them when they stopped giving back. Put another way, we expected the mere act of authoring to reward us, as it often did.

Then we found patterns. We both had Christopher Alexander on our bookshelves. We had noticed that our flip attitude about development was working, producing programs that were used, even reused. Alexander got us thinking that we could can what we were doing and share it too.

I remember Alexander’s emphasis on piecemeal growth. It was fundamental to all of his work and to ours as well. Alexander’s vision went beyond our vision, though, in one important way. He recognized the incredible range of forces that bear on one’s work. He knew that to make a house one must also know how to make a city, and a brick. Then he showed us how to link that know-how together, top to bottom. Awesome.

So that is how I came to be talking about computer plugs. We learned from Alexander that our advice had to be concrete. Who ever learned anything from advice like: make your programs friendly? We had recently had better luck with more concrete advice like: have one pop-up menu, containing verbs, for each pane...

The "unplug" pattern wasn’t about plugs at all. It was about ownership and control. It said take control of the environment in which you write programs. The point of plugs was just the test, something concrete, that would lead you in the right direction without overly constraining what you do.

It’s a good pattern, but not complete. The pattern really only works when surrounded with other patterns that actually give you the ownership and control you’ll need. Kent and I fell into that. We didn’t make it for ourselves. But we recognized we had it, and used it.

The pattern is anything but obsolete today. You’re probably thinking that 99.9 percent of all software written is written on computers that unplug. But can you unplug them? I was thinking about workstations when I first articulated the pattern a decade ago. We thought they would be the locus of power. But it’s turned out servers hold the power now. Can you unplug yours? Can you even get it on the phone?

I maintain an internet presence that I set up with the help of a particularly enlightened provider. I have a server on my premises with a plug that I own. Although the bandwidth of my connection is modest, it is continuous. I’ve found the character of the whole configuration to be categorically better than simpler arrangements. On my machine I run programs that are unwelcome elsewhere: programs that open their own connections, or just run without stopping. I don’t have to ask permission.

We are just consumers to the huge corporations of the computer and telecommunications industry. They want to sell to us all right, but they won’t sell us everything we need; that is, they won’t make us powerful, unless we insist. Pay attention to the pattern. If we computer users are to have and hold the kind of ownership Kent and I have known, we are going to have to watch those plugs.

© 1997, Ward Cunningham
All rights reserved.