What makes a codebase evolvable?

Evolvable is not a property you can see on a diagram of the architecture. It is a property you measure by doing: how long does an ordinary change take, how many files does it touch, how sure are you it broke nothing?

The codebases I have seen age well share a few traits, none of them glamorous.

Boundaries that match the business. When a change in one business concept lands in one place, the code can absorb the next change. When it lands in six places, each of them is a chance to forget one.

Tests that give permission. Not coverage numbers, but a suite fast and trustworthy enough that a developer refactors without asking.

The day a team stops trusting its tests, the codebase stops evolving; it only grows

Dependencies pointing inward. The business rules depend on nothing that ships, deploys or changes for reasons of its own. Frameworks, databases and message brokers sit at the edge, where they can be replaced without renegotiating the core.

A delivery pipeline that tells the truth in minutes. Evolution happens in small steps; small steps need fast, honest feedback. A pipeline that takes an hour, or that is red so often that nobody looks, forces big steps, and big steps are where systems ossify.

Decisions written where the code is. A short note on why something is the way it is saves the next engineer from re-deciding it, or from undoing it for reasons that were already considered.

Nothing on this list needs a rewrite

All of it needs discipline over years, which is why so few codebases have it, and why the ones that do are worth more than any framework.