Law of Leaky Abstractions¶
Spolsky, J. (2002). Law of Leaky Abstractions. Joel on Software.
Cited by¶
6 citations across 6 artifacts.
Each citation links to the sentence it supports in the citing article.
Primes¶
- Abstraction
This sourceCanonical formulation 'all non-trivial abstractions, to some degree, are leaky.' No authoritative link: the sole source is the author's personal blog (joelonsoftware.com), which the linking policy excludes; left link-less. See flag.
Mechanisms¶
- Adapter or Facade Layer
- Its honest failure mode is that no translation is airtight — the substitute's latency, ordering, and failure behavior seep through the wrapper, the Law of Leaky Abstractions in action.
This sourceStates that nontrivial abstractions leak, with latency, failure behavior, and storage-order effects remaining visible through their interfaces.
- Its honest failure mode is that no translation is airtight — the substitute's latency, ordering, and failure behavior seep through the wrapper, the Law of Leaky Abstractions in action.
- Legacy Feature Wrapper
- Under load or at the edges, the old feature's inherited constraints seep through the clean interface and surprise the new consumer with behavior the contract seemed to rule out.
This sourceExplains that non-trivial abstractions leak, exposing underlying constraints and unexpected behavior that the abstraction was intended to hide.
- Under load or at the edges, the old feature's inherited constraints seep through the clean interface and surprise the new consumer with behavior the contract seemed to rule out.
- Object–Arrow Diagram
- Its central failure mode is the leaky abstraction: an object drawn as opaque whose hidden internals secretly govern which arrows are legal, so the picture licenses a mapping that fails in reality.
This sourceExplains that nontrivial abstractions leak when underlying implementation details affect behavior that the abstraction purports to hide.
- Its central failure mode is the leaky abstraction: an object drawn as opaque whose hidden internals secretly govern which arrows are legal, so the picture licenses a mapping that fails in reality.
- Operating System Abstraction
- Joel Spolsky's Law of Leaky Abstractions names the general truth that no non-trivial abstraction fully hides what is beneath it.
This sourceStates that all non-trivial abstractions leak aspects of the complexity they are meant to hide.
- Joel Spolsky's Law of Leaky Abstractions names the general truth that no non-trivial abstraction fully hides what is beneath it.
- Source–Target Mapping Note
- Its failure mode is false completeness: you cannot enumerate every feature of a rich source, and the one you miss is often the one a reader imports — every analogy leaks somewhere.
This sourceStates the law of leaky abstractions: every non-trivial abstraction leaks some underlying complexity through its simplifying interface.
- Its failure mode is false completeness: you cannot enumerate every feature of a rich source, and the one you miss is often the one a reader imports — every analogy leaks somewhere.
Verification¶
Does it exist? Not checked yet. This entry carries no identifier to resolve. It was extracted from the citation as written in the article, normalized, and deduplicated against the rest of the registry.
Does it back the claim? Not recorded. Neither this nor any other of the 6 citations of this work carries a recorded support check.
Was it audited? Yes. A second, independent pass read the citation against the article text and recorded a verdict.
Support is checked per citation rather than per work — the same source can be cited soundly in one article and wrongly in another. Per-citation recording began recently, so a citation with no recorded check is a gap in the record rather than evidence it went unchecked.
See how references were verified.
Registry ID ref:5c9f9d19f110 · see in the full table