A leaky abstraction is any implemented abstraction, intended to reduce (or hide) complexity, where the underlying details are not completely hidden. The term is most frequently used to call attention to a flaw in a software or hardware abstraction.

History

The term "leaky abstraction" appears to have been coined in 2002 by Joel Spolsky

Joel Spolsky

Avram Joel Spolsky is a software engineer and writer. He is the author of Joel on Software, a blog on software development. He was a Program Manager on the Microsoft Excel team between 1991 and 1994. He later founded Fog Creek Software in 2000 and launched the Joel on Software blog...

. However, an earlier paper by Kiczales

Gregor Kiczales

Gregor Kiczales is a professor of computer science at the University of British Columbia in Canada. His best known work is on Aspect-oriented programming and the AspectJ extension for Java at Xerox PARC. He has also contributed to the design of the Common Lisp Object System, and is the author of...

clearly describes some of the issues with imperfect abstractions and presents a potential solution to the problem by allowing for the customization of the abstraction itself.

The Law of Leaky Abstractions

As coined by Spolsky, the Law of Leaky Abstractions states "All non-trivial abstractions, to some degree, are leaky." In making this statement, Spolsky highlights a particularly problematic cause of software defects: the reliance of the software developer on the infallibility of an abstraction.

In Spolsky's article, he calls attention to many examples of abstractions that work most of the time, but where a detail of the underlying complexity cannot be ignored, and thus drives complexity into the software that was supposed to be simplified by the abstraction itself.

Effect on software development

As the systems we use become more and more complex, the number of abstractions that software developers must rely upon increases. Each abstraction attempts to hide complexity, allowing a software developer to create code that can "handle" all the variations in complexity that modern computing requires.

However, if Spolsky's Law of Leaky Abstractions is true, then in order to create software that is reliable, software developers must learn many of the abstraction's underlying details anyway.

Examples

Spolsky cites numerous examples of leaky abstractions that create problems for software development. The following examples are provided in his paper:

• The TCP/IP protocol is the combination of the TCP protocol, which attempts to provide reliable delivery of information, running on top of the IP protocol, which does not ensure reliability. Therefore, on occasion, the IP protocol will fail, and a developer using TCP/IP cannot trust the combination of TCP and IP to address the problem.
• Something as simple as iterating over a large two-dimensional array can have radically different performance if you do it horizontally rather than vertically, depending on the "grain of the wood" -- one direction may result in vastly more page faults than the other direction, and page faults are slow.
• The SQL language is meant to abstract away the procedural steps that are needed to query a database, instead allowing you to define merely what you want and let the database figure out the procedural steps to query it. But in some cases, certain SQL queries are thousands of times slower than other logically equivalent queries.
• Even though network libraries like NFS and SMB let you treat files on remote machines as if they were local, sometimes the connection becomes very slow or goes down, and the file stops acting like it was local, and as a programmer you have to write code to deal with this.
• When writing software for the ASP.NET web programming language, software developers may wish to rely on ASP.NET to abstract away the difference between writing HTML code to handle clicking on a hyperlink () and the code to handle clicking on a button. Problem: the ASP.NET designers needed to hide the fact that in HTML, there's no way to submit a form from a hyperlink. They do this by generating a few lines of JavaScript and attaching an onclick handler to the hyperlink. However, if the end-user has JavaScript disabled, the ASP.NET application doesn't work correctly.