The theatre is not shown, because your system asks for reduced motion. The lecture itself is below, in full.

Lecture · 7 slides

What abstraction costs

8 September 2026

Abstraction is the one technique in programming that is almost never argued against. Duplication is bad, coupling is bad, global state is bad; abstraction is simply good, and more of it is better. A junior engineer is taught to extract a function, then a class, then an interface, and at no point is told what any of that costs.

It costs something. Every abstraction is a promise that you can use a thing without understanding what is underneath it, and that promise is kept less often than the word implies. When it holds, it is the most powerful idea in the field: it is why you can write a program without knowing which processor will run it. When it fails, it fails in a particular and expensive way — the detail you were promised you could ignore surfaces in the middle of something unrelated, and now you must understand both the thing and the layer that was supposed to hide it.

This lecture is not an argument against abstraction, which would be silly. It is an attempt to price it, so the decision to add one can be made with both columns visible.

AssumesYou have at some point added a layer to a program and wondered afterwards whether it helped.

Slide 1
An abstraction is a promise to forget
The definition worth carrying around is not about hiding detail. It is about which details you are being promised you will never need again.
```
interface Store {
  get(key: string): string | null;
  put(key: string, val: string): void;
}
```
typescript
Two methods. Behind them might be a hash map, a file, a database on another continent. The promise is that you may write your program against those two lines and never think about which — and when that promise holds, an enormous amount of code becomes possible to write and to test.
Notice what has been promised away, though. Latency. Failure modes. Whether put is visible to a later get immediately or eventually. Whether the key may contain a slash. Whether two puts at once are safe. Every one of those is a real property of the thing underneath, and the interface has said nothing about any of them.
Slide 2
Every abstraction leaks
Joel Spolsky's law, stated in 2002, is that all non-trivial abstractions leak to some degree, and the years since have not produced a counterexample.
The leak is not a bug in the abstraction. It is what happens when a detail that was abstracted away turns out to affect something you can observe. An object-relational mapper lets you write a loop that looks like it touches memory and in fact issues four hundred queries. A network filesystem looks like a local one until the network is slow, and then it looks like a hung process. Virtual memory makes your program appear to have as much space as it wants, and the program that exceeds physical memory does not fail; it becomes a thousand times slower for reasons invisible in its source.
The cost this imposes is precise: to debug a leaking abstraction you must understand both levels, plus the mapping between them, which is more than you would have needed to know without it.
Slide 3
Indirection is not abstraction
The most common failure is not a leak. It is a layer that hides nothing, because it exposes exactly what it wraps.
```
class UserServiceImpl {
  private UserRepository repo;

  User find(long id) {
    return repo.find(id);
  }
}
```
java
There is a new file, a new interface, a new name to learn, and no detail has been forgotten: the caller still thinks in terms of finding a user by identifier, and the layer has passed the request through unchanged. If the repository grows a second argument, so does this. If it starts throwing, so does this.
A real abstraction lets you stop thinking about something. Indirection just moves where you have to look. The test is simple and worth applying before adding a layer: name the thing a caller no longer needs to know. If you cannot, you are adding a hop, not an abstraction.
Slide 4
The cost you can measure
Some of the price is countable, and it is the smaller half.
Each layer of indirection is a call that may not be inlined, a virtual dispatch that may not be predicted, an allocation that would not otherwise have happened. On modern hardware this is usually irrelevant and occasionally decisive; the cases where it is decisive are inner loops, and they are exactly the cases where people reach for abstraction to tidy up the mess.
The measurable cost also includes build time, binary size, and the number of files someone must open to follow one request from entry to answer. That last one is the bridge to the expensive half: it starts as an inconvenience and becomes, past a certain depth, the reason nobody on the team can hold the system in their head.
Slide 5
The cost you cannot measure
The real price is paid in understanding, and it does not appear in any profile.
An abstraction has to be learned. It has a name that means something slightly different from the ordinary meaning of that word, a set of things it does and does not handle, and a set of situations where it behaves surprisingly. That knowledge lives in one person's head until it lives in nobody's, and the comment that would have explained it was not written because the code was self-documenting.
Worse, a wrong abstraction is harder to remove than duplicated code. Sandi Metz put it as a rule: duplication is far cheaper than the wrong abstraction. Copied code can be deleted in an afternoon by someone who has never seen it before. A layer with nine call sites, each of which has bent slightly to fit it, has to be understood before it can be undone.
Slide 6
Waiting is a strategy
Because abstraction is expensive to remove and cheap to add later, the timing matters more than the design.
The rule of three is crude and works: write it once, write it a second time and wince, and only on the third occurrence look at all three and ask what they have in common. Two examples are not enough to see the shape — the abstraction you would build from two is usually a description of the first one with the second one's differences bolted on, which is why so many configuration options exist.
This is also the honest answer to why premature abstraction is worse than premature optimisation. A slow function can be made fast without anyone else noticing. A wrong interface has to be changed everywhere it is used, and by then it is used in places nobody remembers.
Slide 7
What makes one worth it
Set against all that, the good ones are the foundation of everything, so it is worth being able to recognise them.
A good abstraction is one you can use correctly without reading its implementation, and whose failures are described in its own vocabulary rather than in the vocabulary of what it hides. A file handle is a good abstraction: you can read and write without knowing about sectors, and when it fails it tells you about permissions and disk space, which are file concepts.
The best of them let you forget something permanently. Nobody working today thinks about register allocation, and that is a compiler abstraction that has held for sixty years. Garbage collection removed an entire category of bug from most programs. These are not layers over existing ideas; they are places where somebody found a genuinely simpler way to talk about the problem.
That is the bar, and it is much higher than "this code appeared twice". Most of what is called abstraction in a codebase is filing, and filing has its uses, but it should be recognised for what it is and priced accordingly.

Works in the collection

The arguments above are hanging on the walls of the museum, in one form or another. These are the ones worth looking at next.

The rest of the programme

← All lectures Atrium

An abstraction is a promise to forget

Every abstraction leaks

Indirection is not abstraction

The cost you can measure

The cost you cannot measure

Waiting is a strategy

What makes one worth it

Works in the collection

The rest of the programme