{"id":1179,"date":"2026-04-11T10:00:00","date_gmt":"2026-04-11T09:00:00","guid":{"rendered":"https:\/\/wade.one\/blog\/?p=1179"},"modified":"2026-04-11T10:00:00","modified_gmt":"2026-04-11T09:00:00","slug":"the-best-engineering-decisions-usually-remove-work","status":"publish","type":"post","link":"https:\/\/wade.one\/blog\/2026\/04\/11\/the-best-engineering-decisions-usually-remove-work\/","title":{"rendered":"The Best Engineering Decisions Usually Remove Work"},"content":{"rendered":"

Most of the time, the best engineering decision is not to add something. It is to remove something that is already costing you time.<\/p>\n

That sounds obvious, but teams still drift toward the opposite. When something feels hard, the instinct is often to add another layer: another service, another workflow, another approval, another abstraction, another dashboard. Sometimes that is necessary. More often, it is just a way of moving the discomfort around.<\/p>\n

I have found that the decisions that really improve a system are usually the ones that make future work smaller.<\/p>\n

Remove the thing first<\/h2>\n

If a piece of code, a process, or a dependency no longer earns its keep, deleting it is often the best outcome.<\/p>\n

That is not dramatic. It is just efficient.<\/p>\n

Unused code still has to be read, reviewed, deployed, monitored, and explained. A stale process still makes people stop and ask, “Do we still need this?” A half-useful abstraction still forces everyone to understand its rules before they can change anything else.<\/p>\n

Removing those things does not just clean up the repository. It reduces the number of decisions people have to carry around.<\/p>\n

Simpler boundaries beat clever ones<\/h2>\n

One thing I keep seeing is that complexity hides at the edges.<\/p>\n

You can make a module look neat on its own and still end up with a system that is painful to change because the boundaries are vague. The work spreads out. Everyone starts knowing just enough to be dangerous. Nobody is fully responsible for the seam where things meet.<\/p>\n

Clear boundaries are better than clever design because they make ownership obvious.<\/p>\n

If a boundary is clear, you know where the logic lives, where the data changes, and where failures belong. That is the kind of design that makes the next change cheaper.<\/p>\n

Fewer steps matter more than fancier steps<\/h2>\n

I think a lot of engineering process grows because people are trying to compensate for confusion.<\/p>\n

If the system is hard to reason about, people add more review steps. If releases are scary, they add more gates. If mistakes are common, they add more ceremony. Some of that is reasonable. But if the root cause is unnecessary complexity, then more process just turns one kind of waste into another.<\/p>\n

The better question is usually: what can we remove so the work becomes obvious again?<\/p>\n

That might mean:<\/p>\n