An Essay Argues That Some “Abstractions” Are Really Just Layers of Indirection

# An Essay Argues That Some “Abstractions” Are Really Just Layers of Indirection

*Event date: 2024-12-25*

A new essay on software design takes aim at one of the field’s most overused words. The argument is simple but pointed: not every wrapper, class or interface deserves to be called an abstraction. Some things are genuinely helpful abstractions. Others are just layers of indirection that make code harder to follow, slower to reason about and more expensive to maintain.

The post uses TCP as its clean example. TCP is presented as a good abstraction because it hides the messy details of packet loss, retransmission and ordering. Most developers rarely need to look at those internals, and that invisibility is the point. If an abstraction is working, the user of the abstraction should be able to operate as though the complexity underneath is gone.

The essay then flips to the darker side of the same idea. Thin wrappers that simply forward data, methods that do little more than pass work along and class hierarchies that add ceremony without adding meaning are treated not as elegant design but as burden. They increase cognitive load because the human reader now has more places to look and more relationships to track without getting any new benefit in return.

That critique extends to performance. The author argues that each extra layer is not only a conceptual cost but also a computational one. When debugging or optimizing a system, engineers often have to peel away those layers one by one until they get to the actual work. The more indirection there is, the farther away the team gets from the metal and the harder it becomes to see what the program is really doing.

A particularly sharp point in the essay is that abstraction often rewards the person who creates it more than the people who must live with it. The author suggests that the first developer enjoys cleaner-looking code immediately, while the maintenance burden lands on the next person who has to fix a bug, improve performance or understand why a feature does not behave as expected. In that sense, bad abstraction is a kind of deferred cost.

The essay does not argue against abstraction itself. In fact, it depends on the idea that good abstractions are essential to software engineering. Its claim is narrower and more practical: if a design is merely hiding the route through the code without hiding real complexity, it should not be celebrated as abstraction at all. It is simply an extra layer. The test the author proposes is almost conversational: how often do you have to peek under the hood? The less often, the more likely the abstraction is doing its job.

That framing is likely to resonate because it matches what many engineers feel but do not always say out loud. A system can look modular and still be miserable to work in. The essay’s real contribution is naming that problem cleanly and insisting that clarity, not just structure, is the standard by which abstraction should be judged.