Description
A developer renames a function so that it says what it actually does. The rename is correct. A week later an assistant generates code in another module calling the old name, which it found in a stale example a few directories away, and the build breaks. Two teams lose a day. The fix is to revert the rename, not because the old name was better, but because being correct turned out to cost more than being vague. What the team takes from that is durable: leave the vocabulary alone.
That lesson is the engine. Naming decays the way Lehman said structure decays, under change, unless somebody does the work to hold it together. Parnas named the mechanism: changes made by people who do not know why the original was named that way. Every joiner, every rotation, every contractor arrives with the vocabulary they brought rather than the one the codebase grew, and the terms quietly multiply.
This used to be survivable, because a counter-force existed. Refactoring was the work that pulled the vocabulary back toward coherence, and senior people who remembered the decisions did it in the ordinary course of a week. Both halves of that are weakening at once: generated code arrives faster than anybody consolidates it, and the share of changes that are consolidation rather than addition has been falling.
So this dimension is not the same question as whether your names agree today. It is about the rate. Two systems can look equally inconsistent in a snapshot while one is slowly being repaired and the other is fragmenting, and only one of them is a problem you can still get ahead of. What it scores is whether anybody would be able to tell which one you are.
The five levels
One question decides which rung you are on: does the system itself act on this, or does a human have to choose to? Each rung carries a tell: the thing that would settle it, so the score is something you checked rather than something you agreed with.
- 1
Blind
Nobody is watching the vocabulary move. Duplicates and near-synonyms arrive at whatever rate the work produces them, and there is no way to say whether the system is more coherent than it was last year or less. The question has never been asked, so it has no answer, and the drift compounds unobserved.
The tellAsk who would notice if a second name for an existing concept entered the code this month. If the answer is nobody, or whoever happens to review it, you are here.
- 2
Tacit
Some people notice drift and repair it when they get the chance. A senior engineer consolidates two copies of the same concept in a quiet week; someone renames a confusing type while working in that area. It is real work against a real decay, and it is invisible, unbudgeted, and the first thing dropped when a deadline approaches.
The tellLook through last quarter's delivered work for consolidation or renaming. If you cannot find any that was planned rather than carried along inside a feature ticket, you are here.
- 3
Visible but inert
The drift is measurable and somebody measures it: duplication rates, copy-paste blocks, the ratio of moved code to added code, a similarity report. The numbers exist and get shown at review time. No budget follows them, so the trend is a fact everyone knows and nobody owns.
The tellFind the duplication trend for your scope, then name the last three decisions it changed. No decisions means the number is a report, not something that changes what gets done.
- 4
Acted on
Drift is tracked over time, and the trend is what gets the work scheduled. When duplication or divergence passes the agreed threshold, consolidation is scheduled as delivery rather than requested as a favour, and it happens without anyone having to win an argument about tidiness first.
The tellPoint at the current plan. There is consolidation work in it, and you can name the number that put it there.
- 5
Durable
The repair work is permanent. The budget survives a bad quarter, the measurement itself is maintained when the tooling changes underneath it, and consolidations are followed up to confirm the retired name actually disappeared rather than gaining a third variant.
The tellTake a consolidation from a year ago and check whether the name it retired is still absent. If the old names have crept back, the repair happened once rather than holding.
What this dimension rests on
The five levels are observed, from client engagements, and no paper produced them. What the research below establishes is why this dimension is worth scoring at all. No links: the citations carry enough to find them, and they stay findable after a link would have rotted.
Lehman, Laws of Software Evolution (IEEE 1980)
The second law states that complexity increases and structure deteriorates under change unless work is done to maintain or reduce it. The whole dimension is about whether that work is happening.
Wang et al., Deep Learning-Based Identification of Inconsistent Method Names (Empirical Software Engineering, 2025)
Mined commit histories to classify how names actually drift over time, and found inconsistencies rare enough to be invisible in any single review and systematic enough to reshape a codebase over years.
Where this came from
This dimension has a published article behind it, written from client engagements rather than from a greenfield repository.
Read the article on Semantic drift →
How to climb this dimension is not written yet. It is the next thing this page grows, and saying so is more useful than a paragraph of generic advice.