Tooling and Accidental Complexity

No one decides to make a system heavy. It happens one reasonable choice at a time.

A team adds a caching layer because latency matters. A monitoring tool because visibility matters. A build plugin because developer experience matters. A message broker because decoupling matters. Each addition solves a real problem. Each is justified on its own terms. The weight is not in any single decision. It is in the aggregate.

This is accidental complexity — not complexity born from the problem, but complexity accumulated from the solutions. The system grows heavier than the problem requires, and the weight arrives so gradually that no one notices until a change that should take a day takes a week.

Stack drift is the quiet version of this. The stack you run today is not the stack you chose. It is the stack you chose plus everything that was added to keep it working, plus the things those additions required, plus the compatibility layers that hold the seams together. Nobody designed the full picture. It emerged.

The asymmetry is what makes this hard. Adding a tool is a local decision. One team evaluates it, one team adopts it, and the integration cost seems small. Removing a tool is a global decision. It requires understanding every system that touches it, every pipeline that depends on it, every configuration that references it. Adding takes a week. Removing takes a quarter. So things accumulate.

Configuration is part of the weight, and it is the part that gets the least scrutiny. A YAML file that controls deployment behavior is code. An environment variable that changes runtime behavior is code. A feature flag that alters control flow is code. But none of these go through the same review process as code. They accumulate in places that are harder to search, harder to test, and harder to reason about.

Hidden dependencies are the most expensive form of this. A service that calls another service through an intermediary. A build step that depends on a global state set by a previous step. A test suite that passes only because an unrelated process is running. These dependencies are invisible in architecture diagrams. They show up at 2 AM when an on-call engineer is trying to understand why something that has not changed is suddenly broken.

The system is less resilient than it appears. The diagram shows five services. The reality is five services, three shared libraries, a custom build plugin, two configuration management tools, an internal CLI that nobody remembers writing, and a Makefile that references a Docker image tagged "latest" from 2024. That is the actual system. The weight is real even when it is not visible.

The instinct when this becomes painful is to consolidate. Replace five tools with one platform. Build an internal developer platform. Standardize everything. This sometimes works. But it often introduces a different kind of weight — the weight of the platform itself, which becomes the new thing that is hard to change. The second system is frequently heavier than the first, built to solve every problem the first system had, and a few it did not.

The better response is not consolidation but audit. What is here? Why was it added? Is it still solving the problem it was introduced for? If not, what would it take to remove it? These questions are simple. Answering them honestly is not.

Removal requires understanding that adding was not a mistake. The caching layer was correct when it was introduced. The monitoring tool was the right choice at the time. The message broker solved a real coordination problem. The question is not whether it was a good decision then. The question is whether it is still earning its carrying cost now. Every tool has a carrying cost — in maintenance, in cognitive load, in the time it takes a new team member to understand the system. That cost is never on the invoice.

The systems that stay manageable are not the ones that avoid adding tools. They are the ones that treat removal as a normal part of operations, not as a special project. They notice when something stops earning its cost. They budget time for subtraction, not just addition.

Lightness is not the goal. Intentionality is. A heavy system where every component is justified and understood is better than a light system held together by assumptions. The problem is not weight. It is weight that nobody chose and nobody maintains.

Systems grow heavier than intended because adding is easy and removing is hard. The discipline is not in choosing fewer tools. It is in continuing to ask whether the tools you have are still the right ones.