A leaky abstraction in software development refers to a design flaw where an abstraction, intended to simplify and hide the underlying complexity of a system, fails to completely do so. This results in some of the implementation details becoming exposed or ‘leaking’ through the abstraction, forcing users to have knowledge of these underlying complexities to effectively use or troubleshoot the system.
The concept was popularized by Joel Spolsky, who coined the term Law of Leaky Abstractions which states:
All non-trivial abstractions, to some degree, are leaky.
This means that even well-designed abstractions may not fully conceal their inner workings, and as computer systems grow more complex, the likelihood of such leaks increases. These leaks can lead to performance issues, unexpected behavior, and increased cognitive load on software developers, who are forced to understand both the abstraction and the underlying details it was meant to hide. This highlights a cause of software defects: the reliance of the software developer on an abstraction’s infallibility. Despite their imperfections, abstractions are crucial in software development for managing complexity, even though they are not always flawless.
Examples
Spolsky’s article cites many examples of leaky abstractions that create problems for software development:
- The TCP/IP protocol stack is the combination of TCP, which tries to provide reliable delivery of information, running on top of IP, which provides only ‘best-effort’ service. When IP loses a packet, TCP has to retransmit it, which takes additional time. Thus TCP provides the abstraction of a reliable connection, but the implementation details leak through in the form of potentially variable performance (throughput and latency both suffer when data has to be retransmitted), and the connection can still break entirely.
- Iterating over a large two-dimensional array can have radically different performance if done horizontally rather than vertically, depending on the order in which elements are stored in memory. One direction may vastly increase cache misses and page faults, both of which greatly delay access to memory.
- The SQL language abstracts away the procedural steps for querying a database, allowing one to merely define what one wants. But certain SQL queries are thousands of times slower than other logically equivalent queries. On an even higher level of abstraction, ORM systems, which isolate object-oriented code from the implementation of object persistence using a relational database, still force the programmer to think in terms of databases, tables, and native SQL queries as soon as performance of ORM-generated queries becomes a concern.
- Although network file systems like NFS and SMB let one treat files on remote machines as if they were local, the connection to the remote machine may slow down or break, and the file stops acting as if it were local.
- The ASP.NET web forms programming platform, not to be confused with ASP.NET MVC, abstracts away the difference between compiled back-end code to handle clicking on a hyperlink () and code to handle clicking on a button. However, ASP.NET needs to hide the fact that in HTML there is no way to submit a form from a hyperlink. It does 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 malfunctions. Furthermore, one cannot naively think of event handlers in ASP.NET in the same way as in a desktop GUI framework such as Windows Forms; due to the asynchronous nature of the Web, processing event handlers in ASP.NET requires exchanging data with the server and reloading the form.
In 2020, Massachusetts Institute of Technology computing science teaching staff Anish, Jose, and Jon argued that the command line interface for git is a leaky abstraction, in which the underlying “beautiful design” of the git data model needs to be understood for effective usage of git.