Go to previous post:
Katha Pollitt

Go to Electrolite's front page.

Go to next post:
If you’re confused

Our Admirable Sponsors

November 13, 2002

Why Systems Fail: Via BoingBoing, and also Scott Rosenberg’s weblog, here’s a terrific essay about the power and pitfalls of abstraction. The focus is on software development, but it’s entirely readable by non-programmers like me, and the relevance of its points to other endeavors is obvious.
As it turns out, a lot of computer programming consists of building abstractions. What is a string library? It’s a way to pretend that computers can manipulate strings just as easily as they can manipulate numbers. What is a file system? It’s a way to pretend that a hard drive isn’t really a bunch of spinning magnetic platters that can store bits at certain locations, but rather a hierarchical system of folders-within-folders containing individual files that in turn consist of one or more strings of bytes.

Back to TCP. Earlier for the sake of simplicity I told a little fib, and some of you have steam coming out of your ears by now because this fib is driving you crazy. I said that TCP guarantees that your message will arrive. It doesn’t, actually. If your pet snake has chewed through the network cable leading to your computer, and no IP packets can get through, then TCP can’t do anything about it and your message doesn’t arrive. If you were curt with the system administrators in your company and they punished you by plugging you into an overloaded hub, only some of your IP packets will get through, and TCP will work, but everything will be really slow.

This is what I call a leaky abstraction. TCP attempts to provide a complete abstraction of an underlying unreliable network, but sometimes, the network leaks through the abstraction and you feel the things that the abstraction can’t quite protect you from. This is but one example of what I’ve dubbed the Law of Leaky Abstractions:

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong.

Earlier in the essay, the author provides the best description I’ve ever seen of how TCP/IP—the basic communication protocol of the internet — actually works. Wayward Broadway actors and UFO crashes are involved. No, really. [08:35 AM]
Welcome to Electrolite's comments section.
Hard-Hitting Moderator: Teresa Nielsen Hayden.

Comments on Why Systems Fail::

Myke ::: (view all by) ::: November 13, 2002, 10:12 AM:

That *is* really cool. When you really think about it, pretty much everything having to do with computers is an abstraction. Even programming languages are a way to pretend that you are coding a comprehensible language that both you and the system comprehend, rather than simply manipulating long strings of "1"s and "0"s.

Erik V. Olson ::: (view all by) ::: November 13, 2002, 11:43 AM:

Everything we deal with in computing is an abstraction, because it is too difficult to do everything concretely. If we had to do everything as direct assembler opcodes, computing would be orders of magnitude harder, orders of magintude less efficent, and orders of magintude more expensive.

I must note an error.

If you put users' home directories on NFS-mounted drives (one abstraction), and your users create .forward files to forward all their email somewhere else (another abstraction), and the NFS server goes down while new email is arriving, the messages will not be forwarded because the .forward file will not be found. The leak in the abstraction actually caused a few messages to be dropped on the floor.

Incorrect. The messages aren't dropped on the floor. They're in the user's spool on the machine (since it didn't see the .forward file) and they'll remain there. If you lose an NFS mount that has account homes, one of the things you do is check the spools. "Dropped on the floor" means "Gone and lost forever." In this case, it's not. Just restart the NFS server, when it is up, resubmit those messages to the queue.

Abstraction is good. Many of the problems the author notes (the Windows COM development wizards, SQL performance efficenices (which are real -- "SELECT INTO" == "Destroy Performance" on most RDMBSs) C++ string "handling") are poor designs. He's right that leaky abstractions are causing us problems. But I sense he thinks less abstraction would be good. I don't know if we can afford that. Better abstraction would be better.

He also conflates, a couple of times, "abstraction" and "mitigation." Wipers and headlights and heaters don't abstract away weather. They migitate the visibility and temperature effects of weather, to a certain extent. But they don't abstract weather away. Both abstraction and mitigation deal with complexities, but they're different things, and coflating them is, well, poor abstraction.

Debra Doyle ::: (view all by) ::: November 13, 2002, 12:34 PM:

"All non-trivial abstractions, to some degree, are leaky."

Or, as the linguist Edward Sapir once famously observed, "All grammars leak." Of course, a grammatical system is itself a non-trivial abstraction.

Stefan Jones ::: (view all by) ::: November 13, 2002, 01:06 PM:

I spent years as a computer worker who knew really nothing about how computers work. When I finally decided to go back to school and take actual CS courses, I was at first utterly intimidated. My Computer Architecture text was . . . terrifying. Lines and little symbols and bizarre tables.

As for C . . . yow! Pointers.

After a couple of weeks, I pushed my pointy noggin through the caul and the cold brilliant light flooded in. The key was understanding layers of abstraction and indirection.

"Wayward Broadway actors and UFO crashes"

Man, this sounds great. Kind of like the way Neal Stephenson worked power drills and gas stations into "In the Beginning was the Command line."

Myke ::: (view all by) ::: November 13, 2002, 02:08 PM:

Computer science is a lot like building/construction projects. From a distance, it really does seem like alchemy, but the moment a reasonably smart person sits down, cracks open a how-to book and really starts to dig in, it's surprisingly easy as long as you are able to follow directions meticulously.

If a bona fide moron like me can gut/renovate his bathroom, and run a big enterprise network, then *anyone* can.

I wish writing were just as straightforward. The nice thing about computers is if you do A, you are pretty much guaranteed to get B. There's very little that's subjective.

Charles ::: (view all by) ::: November 13, 2002, 02:15 PM:

He's missed one major point. Computers allow us to manipulate abstractions as easily as if they were data. If an abstraction of that string array doesn't work well for our purposes, just switch abstractions and deal with the memory as an array of numbers.

Mike Kozlowski ::: (view all by) ::: November 13, 2002, 08:19 PM:

Erik: I don't think Joel wants to do away with abstractions. (He's a professional programmer, after all.) I think his point is just that it's dangerous not to know what's underneath the abstraction, that there is a difference between those who fundamentally understand and those who superficially understand.

Erik V. Olson ::: (view all by) ::: November 13, 2002, 08:47 PM:

Well, the way he missed twice on techinical points bothers me on how much we can trust his opinion. I'd forgive him for not understanding how email works -- he's a developer, not a sysadmin, but his comments about windshield wipers abstracting away weather show me that he really does not understand the difference between simplification, abstraction, and mitigation.

And, as we go along, we have to abstract more and more. From source to executed code now features three levels of abstraction, and in some cases more, in order to control the complexity.

I do agree that both SQL and C++ have real abstraction issues. But they've had real abstraction issues for years, and knowing how to get around them is part and parcel what a good developer does. Ideally, we wouldn't teach people how to work around the bad abstractions -- we'd build languages that didn't do such poor abstractions. Alas, we don't live in an ideal world.

Sylvia Li ::: (view all by) ::: November 14, 2002, 01:06 PM:

I for one am grateful to him for articulating so well something I've known to be true since... hmm, since 1965 when I worked in 1401 Autocoder and RPG.

The 1401, for those too young to have heard of it, was an IBM computer from the time after transistors, but before integrated circuits. Autocoder was a one-for-one representation of the 1401's instruction set; Autocoder programmers would routinely punch patches on cards to insert into object decks, and had to write their own device I/O and error handling routines. RPG, back then in its first iteration, was an abstraction of plugboard accounting machines superimposed on the 1401 architecture -- a very, very leaky abstraction.

You could not be an RPG programmer at all without understanding quite a bit about the quirks of the way the abstraction had been implemented. You could be an RPG programmer without having all the skills needed to be an Autocoder programmer, but you couldn't be a good one because sooner or later you were sure to run into one of the places where hardware architecture poked through the abstraction.

Today's high-level languages are much better at shielding you from lower levels. In this respect C and its descendants are not good examples. C was originally designed for writing an operating system, not applications. Some of the design decisions made then for, really, quite era-specific reasons, have been locked into its structure, and continue to show up in C++ and even Java. Languages that aren't constrained by inheritance from C are free to do a better job of abstraction, and they mostly do.

Nevertheless, it's still true that knowing the underlying layers can come in handy at the oddest times.