leaky-abstractionslisted

# Law of Leaky Abstractions > "All non-trivial abstractions, to some degree, are leaky." > — Joel Spolsky, 2002 ## The core idea An abstraction is a simplification: it hides complexity and lets you work at a higher level. TCP hides the complexity of packet routing. An ORM hides the complexity of SQL. A garbage collector hides the complexity of memory management. But all non-trivial abstractions eventually fail to hide everything. The underlying complexity leaks through — and when it does, you need to understand both the abstraction *and* the thing it was supposed to abstract. This is not a solvable problem. It is a fundamental property of abstraction. ## Classic examples **TCP over lossy networks:** TCP presents a "reliable pipe" abstraction. But if the network is slow or lossy, TCP's retry behavior becomes visible through degraded performance. To reason about the slowdown, you need to understand TCP internals. **ORMs:** SQL ORMs promise you don't need to write SQL. But an ORM that generates a SELECT N+1 query pattern will be slow, and diagnosing it requires understanding the SQL being generated — which the ORM was meant to hide. **Iterating over a large file in a high-level language:** The abstraction promises "just loop over lines." But if the file is huge and you run out of memory, you need to understand buffering, paging, and how the OS reads files. **Remote procedure calls (RPCs):** RPC frameworks promise "call a remote function like a local one." But network f