At Stepsize we believe that technical debt should be understood and managed using clear metrics rather than feelings and anecdotes.
When uncertainty is high, moving quickly by taking on debt is the shortest path to understanding how a system should be built and for what purpose. However, successful projects eventually reach a state where the interest on this debt is too high and it's time to pay back the principal — it's become too difficult to contribute to the project and it's time to refactor it using everything the team has learned.
Effective technical leaders know this, but they've never had the tools to measure the impact of tech debt, prioritise efforts to pay it back, and track their progress.
This document outlines 3 metrics that can be used for that purpose.
Ownership is a leading indicator of engineering health.
The parts of the codebase receiving contributions from many people accumulate cruft over time, while those receiving contributions from fewer people tend to be in a better state. It's easier to maintain high standards in a tight group that is well-informed about their part of the codebase.
This provides some predictive power: weakly owned parts of the codebase are likely to accumulate debt over time and become increasingly hard to work with. In particular, it's likely for debt to be unintentionally taken on, simply as a side-effect of incomplete information and diluted ownership of the code's quality.
This is somewhat analogous to the tragedy of the commons.
Ownership is computed by looking at the blame data of the current revision, the historical activity of each file, and blending the two numbers while applying a time discounting factor to favour recent activity.
It can be computed at the level of teams or individual contributors, and can be aggregated over any subset of the codebase.
We call contributors with more than n% of ownership "major contributors" and all others contributors "minor contributors". (n is 5 by default.)
Don’t Touch My Code! Examining the Effects of Ownership on Software Quality — Microsoft Research
Microsoft explored two hypotheses on the Windows Vista & Windows 7 codebases:
Hypothesis 1 Software components with many minor contributors will have more failures than software components that have fewer
Hypothesis 2 Software components with a high level of ownership will have fewer failures than components with lower top ownership levels