Most of the time, the best engineering decision is not to add something. It is to remove something that is already costing you time.
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.
I have found that the decisions that really improve a system are usually the ones that make future work smaller.
Remove the thing first
If a piece of code, a process, or a dependency no longer earns its keep, deleting it is often the best outcome.
That is not dramatic. It is just efficient.
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.
Removing those things does not just clean up the repository. It reduces the number of decisions people have to carry around.
Simpler boundaries beat clever ones
One thing I keep seeing is that complexity hides at the edges.
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.
Clear boundaries are better than clever design because they make ownership obvious.
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.
Fewer steps matter more than fancier steps
I think a lot of engineering process grows because people are trying to compensate for confusion.
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.
The better question is usually: what can we remove so the work becomes obvious again?
That might mean:
- deleting a feature that does not matter
- collapsing two similar code paths into one
- removing a manual deployment step
- narrowing the number of ways a thing can be configured
- cutting a layer that only exists because somebody was worried about a future problem
That list is not glamorous, but it is where a lot of the real value lives.
Good architecture usually looks boring
I trust architecture more when it makes the system easier to explain in plain language.
If the design requires a long apology, that is usually a sign. If the only reason for a layer is that it sounds scalable, that is also a sign. If the main benefit of a change is that it will let the team keep adding more things later, but the current work gets harder right away, I would want a stronger reason.
Good architecture should remove uncertainty.
It should make it easier to see what changed, easier to test the right thing, easier to roll back, and easier to hand off. If it does not do that, it is probably just another kind of work.
The useful question
When I am looking at a decision, I try to ask a simple question:
What work disappears if we do this?
Not what looks smarter. Not what sounds more robust. Not what would be impressive in a diagram.
What work disappears.
If the answer is that we remove repeated steps, reduce support burden, shorten the path to a fix, or make the next change easier to understand, I am usually interested. If the answer is just that we added more machinery, I am much less interested.
That is probably the clearest rule I have for this kind of work. The best engineering decisions usually make the system smaller in the ways that matter.