January 2007

Anything You Can Do, I Can Do Meta

Continued from page 13

By Scott Rosenberg

Audio »

Favorite

E-mail

The Law of Leaky Abstractions
Excerpted from Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software , by Scott Rosenberg, to be published by
Crown Books in January 2007.

Software, we've seen, is a thing of layers, with each layer translating information and processes for the layers above and below. At the bottom of this stack of layers sits the machine with its pure binary ones and zeros. At the top are the human beings, building and using these layers. Simonyi's Intentional Software, at heart, simply proposes one more layer between the machine and us.

Software's layers are its essence, and they are what drive progress in the field, but they have a persistent weakness. They leak. For instance, users of many versions of Microsoft Windows are wearily familiar with the phenomenon of the Blue Screen of Death. You are working away inside some software application like a Web browser or Microsoft Word, and suddenly, out of nowhere, your screen turns blue and you see some white text on it that reads something like this:

A fatal exception 0E has occurred at
0167:BFF9DFFF.

The current application will be terminated.

Eyeing the screen's monochrome look and the blockish typeface, veteran users may sense that they have been flung backward in computer time. Some may even understand that the message's alarming reference to a "fatal exception" means that the program has encountered a bug it cannot recover from and has crashed, or that the cryptic hexadecimal (base 16) numbers describe the exact location in the computer's memory where the crash took place. None of the information is of any value to most users. The comfortable, familiar interface of the application they were using has vanished; a deeper layer of abstraction--in this case, the Windows "shell" or lower-level control program--has erupted like a slanted layer of bedrock poking up through more recent geological strata and into the sunlight.

(Perplexing as the Blue Screen of Death is, it actually represented a great advance from earlier versions of Windows since it sometimes allows the user to shut down the offending program and continue working. Before the blue screen, the crash of one Windows program almost always took down the entire machine and all its programs.)

In an essay titled "The Law of Leaky Abstractions," Joel Spolsky wrote, "All non-trivial abstractions, to some degree, are leaky. Abstractions fail. Sometimes a little, sometimes a lot. There's leakage. Things go wrong." For users this means that sometimes your computer behaves in bizarre, perplexing ways, and sometimes you will want to, as Mitch Kapor said in his Software Design Manifesto , throw it out the window. For programmers it means that new tools and ideas that bundle up some bit of low-level computing complexity and package it in a new, easier-to-manipulate abstraction are great, but only until they break. Then all that hidden complexity leaks back into their work. In theory, the handy new top layer allows programmers to forget about the mess below it; in practice, the programmer still needs to understand that mess, because eventually he is going to land in it. Spolsky wrote:

Abstractions do not really simplify our lives as much as they were meant to. ... The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying, "Learn how to do it manually first, then use the wizzy tool to save time." Code-generation tools that pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning. ... And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

So even though "the abstractions we've created over the years do allow us to deal with new orders of complexity in software development that we didn't have to deal with ten or fifteen years ago," and even though these tools "let us get a lot of work done incredibly quickly," Spolsky wrote, "suddenly one day we need to figure out a problem where the abstraction leaked, and it takes two weeks."

The Law of Leaky Abstractions explains why so many programmers I've talked to roll their eyes skeptically when they hear descriptions of Intentional Programming or other similar ideas for transcending software's complexity. It's not that they wouldn't welcome taking another step up the abstraction ladder; but they fear that no matter how high they climb on that ladder, they will always have to run up and down it more than they'd like--and the taller it becomes, the longer the trip.

Anything You Can Do, I Can Do Meta

Would you like to read more articles from the January/February 2007 issue?

Comments

Related Articles

Current Issue

Magazine Services

Career Resources

MIT Technology Insider

More Technology News from

Wire Stories