Look, this isn’t about some abstract concept. It’s about your Tuesday. It’s about the senior engineer tracing a six-millisecond request that’s somehow taking eight hundred. It’s about the junior engineer staring at a screen full of YAML, wondering what a kubelet even is. This is about what happens when we build systems so layered, so wrapped in abstractions, that nobody remembers what the actual problem was in the first place.
We reach for the layer. It’s a universal reflex. Code. Infrastructure. Process. Organization. Wrap an API in a client. A client in an adapter. An adapter in a service object. A service object in a factory. Deployments get pipelines. Pipelines get operators. Operators get platforms. Platforms get portals. Teams get tribes. Tribes get chapters. Centers of excellence. The plaster fits every wound. The wound itself? Never examined.
This impulse is so ingrained, the alternative barely registers. Could we remove the underlying thing instead of wrapping it? Rarely asked. The team that built the thing is in the next room. The project’s in a past quarter’s review. The engineer who’d have to dig it out has thirteen tickets that close more cleanly with another wrapper. So the wrapper goes in. A year later, it gets a wrapper.
Why Did This Happen? The Myth of Containment
Layered architecture had a noble origin. Dijkstra, 1968. Disciplined layering to bound complexity. Each layer presented a defined interface. You could reason about one layer without the whole damn stack in your head. Brilliant. Still is.
Then Parnas, four years later, gave us Information Hiding. Hide what changes behind a stable interface. Change in one place doesn’t break everything else. Layers were an application of this. The intent was to contain complexity. Not defer it.
Somewhere between Parnas and the third generation of cloud abstractions, the verb shifted. Containing became postponing. The layer that once prevented leakage now exists solely to defer the moment you have to look at the messy bits below. The Kubernetes operator doesn’t hide a stable abstraction; it hides YAML nobody wants to read. The retry decorator doesn’t bound a clean interface; it papers over an upstream service that’s perpetually broken. The ORM doesn’t abstract the database; it postpones the conversation about what the actual queries should be.
The vocabulary survived. The discipline? Gone.
The Cost of Complexity: More Than Just Slowdowns
Lehman’s second law of software evolution: complexity increases unless explicit work is done to maintain or reduce it. Few sentences aged better. He compared it to thermodynamics. Entropy is default. Order requires energy. And that energy? It’s the work nobody funds because it ships no new features, closes no tickets, and leaves no fancy diagrams for the architecture review.
We end up with defensive code paths multiplying. Every API call gets retries. Every value gets null checks. Every cache gets invalidation logic. Phil Karlton famously said there are two hard things: cache invalidation and naming things. We’ve industriously made the first one our default architectural pattern, and we still can’t agree on the name of the variable holding the result.
The cost isn’t just the cache. It’s the people. The Senior Engineer spends her morning tracing why six milliseconds became eight hundred. She navigates retry decorators, adapter classes, a service mesh sidecar, a fallback strategy untouched since 2023. At the bottom? A database query missing an index. Index goes in. Eight hundred milliseconds become six. The retry decorator stays. The adapter stays. The sidecar stays. Removing them? Another quarter’s work. The quarter has other plans.
What’s lost is not just efficiency. It’s clarity. It’s the ability to reason about the system. It’s the fundamental joy of building something that works, rather than managing something that’s perpetually held together with digital duct tape and arcane configurations. This isn’t just a technical problem; it’s a cultural one. We’ve rewarded the appearance of progress—shipping features wrapped in new abstractions—over the hard, unglamorous work of true engineering: understanding, simplifying, and removing.
When something does not work as wished, one adds a layer on top.
This is the problem. We don’t ask if the original thing is broken; we just plaster over it. And then we complain when the plaster needs its own plaster.
Is there an alternative? Of course. It involves difficult conversations, refactoring, and acknowledging that sometimes, the quickest path forward is backward—to the core problem that was so conveniently hidden.
We need to ask ourselves: are we building a system, or are we building a monument to postponed decisions? Because right now, it feels a lot like the latter.
Is This What Open Source is For?
One might expect open source to be the antidote. A place where transparency reigns, where the layers are visible, where the underlying code can be inspected and understood. And sometimes, it is.
But even in open source, the same pressures apply. Popular projects become complex ecosystems. Developers seeking to contribute often face the same choice: hack on the existing wrapper, or spend months understanding the deep internals to remove a layer. The path of least resistance, of course, is another wrapper. It’s easier to add a new configuration flag to an operator than it is to refactor the operator’s underlying logic.
This creates a curious irony. We champion open source for its inspectability, yet the very tools that make it accessible often become opaque themselves. The promise of understanding the machine breaks down when the machine is twenty layers deep.
The pattern is invisible because it is universal. We do it in code, in infrastructure, in process, in organisation.
This statement, plucked from the source material, is the grim reality. It’s not a bug; it’s a feature of our collective approach. The tools might be open, but the path to true comprehension is increasingly barricaded.
What does this mean for the future? More complexity. More confusion. More engineers spending their days untangling knots rather than forging new paths. Unless, of course, we consciously decide to embrace the hard work of simplification. That means valuing the removal of code as much as its addition. It means funding projects that focus on clarity and reduction, not just feature velocity.
It’s a tough sell. But the alternative is a software landscape where the engineers are slaves to the complexity they themselves have created, forever chasing ghosts in the machine.
