leaky abstraction

programmingweb dev

An abstraction that is supposed to hide complexity but lets details of what is underneath show through.

TCP promises reliable delivery, but a cut cable still surfaces as a hang; an ORM hides SQL until a slow query forces you to think in SQL again. Joel Spolsky's 'law' is that all non-trivial abstractions leak to some degree, so you can never fully stop understanding the layer below.

Joel Spolsky's law of leaky abstractions says all non-trivial abstractions, to some degree, are leaky. The abstraction hides the complexity underneath until the moment it cannot, and then the details it was hiding become urgently relevant to someone who was deliberately not taught them.

The examples are everywhere once you look. A network file share behaves like a local disk until the network is slow, and then the abstraction leaks latency and partial failures that local files never had. An ORM hides SQL until a query plan is catastrophic. TCP presents a reliable stream over an unreliable network, and mostly succeeds, until packet loss turns into throughput collapse that only makes sense one layer down.

The consequence is uncomfortable for how the industry teaches. Abstractions save time and they do not save learning: the person maintaining the system still needs to understand what is underneath, because the failures come from there. That is why senior engineers are valuable in a way that is hard to articulate on a CV. They know which abstraction is leaking, which is knowledge only obtainable by having been surprised before.

Also known as: law of leaky abstractions

← All glossary entries