Knowledge distribution · Change coupling
Give every component an owner, and watch the drive-by edits
The number of low-ownership contributors to a component predicts its pre-release and post-release failures after controlling for size, complexity and churn — in two large systems it was more strongly correlated with defects than any other metric that organisation collected.
Do this firstNothing. This is a place to start.
Not a gate. A number to look at.
The finding underneath this control is narrower and more interesting than “have owners”: it is that minor contributors — people who touched a component while holding almost no ownership of it — carry the signal. A component with one clear owner and eleven people who each edited it once is the shape that predicts failures, and it is a shape that no size, complexity or churn metric detects.
The intervention is correspondingly modest. Know who owns each component, make the drive-by edits visible, and treat a rising minor-contributor count as a prompt to bring somebody properly into the component rather than as a rule forbidding the edit.
The decoy
Collective ownership of everything. It is a real and defensible position, and it is not the same thing as nobody having looked at a component in a year. The measurable risk is not shared ownership; it is the count of contributors with almost no stake in a component who each changed it once.
Evidence
- Don't Touch My Code! Examining the Effects of Ownership on Software Quality — IIAdding ownership metrics — particularly the count of low-ownership 'minor' contributors — substantially increased explained variance in failures, from 26% to 46% pre-release in one system and from 24% to 70% in the other. Minor contributor count correlated with defects more strongly than any other metric the organisation collected.
Last reviewed 2026-08-19.