Description
Review is where generated code meets human judgement, and routing decides whose. When everything touching an area goes to the person who owns it, tripling the volume does not triple that person. It lengthens their queue, and then, quietly, it lowers the standard of what comes out of the queue, because the alternative is becoming the reason nothing ships.
The research most often cited for narrow ownership says something narrower than people think. Studying large commercial systems, the strongest predictor of defects was change made by contributors with little ownership of the component: people who arrive, make a change and leave without much context. That is an argument against low-familiarity contributions, not against many people knowing the code well. It is also worth noticing where a generated change starts. It has no history with the module at all, which is exactly the profile that finding describes.
The second thing the research says is that review is how ownership is built. Across large projects, most contributors know a module through reviewing it rather than writing it, and ownership models that count review track quality more closely than those counting authorship alone. Narrow routing sends every review to one person, which is precisely the mechanism that would have spread the knowledge, so the bottleneck reproduces itself.
Then the arithmetic stops working. Human review has a known effective rate, and beyond it defect detection falls off sharply. Changes are getting larger and more frequent at the same time. That leaves three options: lower the standard quietly, accept a queue that delays everything, or spread the load across people who genuinely know the area. Only one keeps both quality and flow, and this dimension scores whether your routing was designed for it or arrived by habit.
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
There is no map of who can review what. Changes find reviewers by proximity and habit, nobody measures how long they wait, and the concentration of knowledge stays invisible until somebody leaves and the team finds out what left with them.
The tellOpen the last twenty merged changes to your most critical service and count the distinct reviewers. If it is one or two names, and nothing anywhere records who else could have done it, you are here.
- 2
Tacit
Review works because a handful of people carry it. They know the critical areas, they get asked for anything that touches them, and the quality of review across the organisation is largely the quality of their attention. It holds until their queue outgrows their week.
The tellCount how many changes to your most critical area went to the same reviewer last month. If one name is on most of them, review is concentrated whether or not anyone designed it that way.
- 3
Visible but inert
Routing is codified. There is a CODEOWNERS file or its equivalent, and it correctly names who owns what. Nothing watches what happens behind it: a reviewer's queue can grow all quarter and the waits can double, and the file keeps sending everything to them because that is what it says.
The tellLook at the review waiting time for your busiest owner across the last quarter. If it rose and nothing in the routing changed, the file records who owns what and does not act on it.
- 4
Acted on
Routing is designed for breadth and responds to load. Changes reach more than one qualified reviewer, review-queue depth is monitored, and a queue past the agreed depth reroutes work or raises a flag on its own instead of waiting for the reviewer to admit they are drowning.
The tellFind the last time one reviewer's queue passed its limit. Something rerouted or escalated automatically because of the depth, rather than a person volunteering that they were behind.
- 5
Durable
Breadth is maintained rather than assumed. How many people can review each critical area is known and deliberately grown, review is treated as the way knowledge spreads rather than as a gate to pass, and a resignation does not leave an area with one qualified reader.
The tellCompare how many people can review each critical area now with a year ago. If the number held or grew across joiners and leavers, the breadth is being maintained rather than remembered.
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.
Bird, Nagappan, Murphy, Gall and Devanbu, Don't Touch My Code! Examining the Effects of Ownership on Software Quality (ESEC/FSE 2011)
Found that changes made by contributors with little ownership of a component predict defects better than most code measures. Low familiarity is the risk, which is exactly the position a generated change starts from.
Thongtanunam, McIntosh, Hassan and Iida, Revisiting Code Ownership and Its Relationship with Software Quality in the Scope of Modern Code Review (ICSE 2016)
Showed that most contributors know a module through reviewing it rather than writing it, and that ownership models counting review relate more closely to quality than models counting authorship alone.
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 Code ownership and review routing →
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.