That's Not an Abstraction, That's Just a Layer of Indirection

If you've ever worked on refactoring or improving performance in a software system, you've probably run into a particular frustration: abstraction-heavy codebases. What looks like neatly organized and modularized code often reveals itself as a labyrinth, with layers upon layers of indirection. The performance is sluggish, debugging is a nightmare, and your CPU seems to be spending more time running abstractions than solving the actual problem. This leads us to an important realization: not all abstractions are created equal. In fact, many are not abstractions at all—they're just thin veneers, layers of indirection that add complexity without adding real value.

An abstraction is only as good as its ability to hide the complexity of what lies underneath. Think of a truly great abstraction, like TCP. TCP helps us pretend that we have a reliable communication channel, even though it's built on top of an unreliable protocol, IP. It takes on the complexity of error correction, retransmission, and packet sequencing so that we don't have to. And it does such a good job that, as developers, we very rarely have to peek into its inner workings. When was the last time you had to debug TCP at the level of packets? For most of us, the answer is never.

That’s the sign of a great abstraction. It allows us to operate as if the underlying complexity simply doesn't exist. We take advantage of the benefits, while the abstraction keeps the hard stuff out of sight, out of mind.

Leave a Comment