The Law of Leaky Abstractions

The Law of Leaky Abstractions

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

All non-trivial abstractions, to some degree, are leaky.

Abstractions fail. Sometimes a little, sometimes a lot. There’s leakage. Things go wrong. It happens all over the place when you have abstractions. Here are some examples. One reason the law of leaky abstractions is problematic is that it means that abstractions do not really simplify our lives as much as they were meant to.

  1. The SQL language is meant to abstract away the procedural steps that are needed to query a database, instead allowing you to define merely what you want and let the database figure out the procedural steps to query it.
    1. But in some cases, certain SQL queries are thousands of times slower than other logically equivalent queries.
    2. A famous example of this is that some SQL servers are dramatically faster if you specify “where a=b and b=c and a=c” than if you only specify “where a=b and b=c” even though the result set is the same.
    3. You’re not supposed to have to care about the procedure, only the specification.
    4. But sometimes the abstraction leaks and causes horrible performance and you have to break out the query plan analyzer and study what it did wrong, and figure out how to make your query run faster.
  2. And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.

Implications of The law of leaky abstractions

  1. You hear a lot of people saying learn how to do it manually first, then use the wizzy tool to save time.
  2. The only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting.
  3. So the abstractions save us time working, but they don’t save us time learning.
  4. And all this means that paradoxically, even as we have higher and higher level programming tools with better and better abstractions, becoming a proficient programmer is getting harder and harder.

Links to this note