Codebase Age Matters More Than Team Size

Two teams of six. Same stack, same seniority on paper, similar problem domain. One ships weekly without drama. The other has a three week cycle and a release that everyone dreads. The usual explanation is people, or process, or discipline. Usually it is none of those. It is that one codebase is four years old and the other is eleven months old.

What accumulates

Age is not a proxy for size. Some very large codebases are pleasant to work in and some small ones are miserable. What accumulates with age specifically is coupling that nobody chose: the call added under deadline that quietly became load-bearing, the column that means two different things depending on which year the row was written, the workaround for a bug in a dependency that was fixed six years ago.

None of these are visible in a line count. All of them extend the distance between deciding to change something and knowing whether you broke it.

The measurement that tells you where you are

Headcount and lines of code both predict very little. Two things predict a lot.

The first is time from merge to production. This is a direct measurement of how much ceremony a change has accumulated, and it is very hard to argue with because it is wall-clock.

The second is the share of changes that touch more than three modules. In a young codebase most changes are local. As coupling accumulates, an increasing share of ordinary work becomes cross-cutting, and cross-cutting work is where estimates go to die.

Why adding people makes it worse

The instinct when a mature codebase slows down is to add engineers, which is the one intervention guaranteed to fail. Onboarding cost scales with accumulated coupling, not with system size, because what a new engineer has to learn is not the architecture but the exceptions to it. The architecture is written down. The exceptions are in people's heads.

So the new engineer is slow for longer, and gets that context by consuming the time of the people who hold it, who were the constraint to begin with.

What works instead

Spend on shortening the feedback loop rather than on parallelism. A test suite that runs in four minutes rather than forty changes how often people are willing to try something, and willingness to try things is most of what looks like velocity.

Then delete. Not refactor, delete. Every retired feature and dead column removes coupling permanently, and unlike a refactor there is no risk of reintroducing it later.

Compare a team against its own numbers six months ago. Comparing it against a younger team measures the age difference, and then blames the people.