Most engineering advice is about building things to last. Less is said about building things to remove — yet in long-lived systems, the ability to delete code cleanly is what keeps the whole thing from rotting.
A system you can delete pieces of is a system you understand. It has clear seams, honest boundaries, and few load-bearing assumptions hiding in the dark.
The cost of permanence
Every abstraction is a bet that the future will look a certain way. When that bet is wrong, the abstraction does not just become useless — it becomes a tax on everyone who has to work around it.
The best abstraction is the one you can throw away without anyone noticing.
When something is cheap to remove, you are free to be wrong about it. That freedom is what lets a codebase keep moving as the product changes underneath it.
Build along the seams
Draw boundaries where the system naturally wants to come apart, not where a diagram says it should. A good seam is one where you can swap or delete what is on either side without the other side caring.
In practice this means small modules with narrow interfaces, dependencies that point one direction, and as little shared mutable state as you can get away with.
A test for abstractions
Before adding a layer, ask: if this turns out to be wrong, how hard is it to pull back out? If the answer is "we would never dare," that is not an abstraction — it is a foundation, and you should treat it with far more care.
Optimise for reversibility, and most other good properties tend to follow.
