7.2 Software Metrics Used Carefully
Software metrics can help teams see trends, bottlenecks, and risks. They can also hurt a team: once a metric becomes a simple reward or punishment target, people optimize the number instead of the system.
Metrics should start conversations, not act as a hammer.
What Common Metrics Can Show
Different metrics provide different signals:
- LOC can show size change, but not value.
- Cyclomatic complexity can signal testing and review risk, but not automatically bad code.
- Defect density can show quality trends, but needs module complexity and usage context.
- Churn can highlight recently changing areas, especially when combined with defects and incidents.
- Lead time can reveal waiting, approval bottlenecks, and large batch size.
The more a metric is separated from context, the easier it is to misuse.
Metrics Change Behavior
If people are rewarded for lines of code, the team may write more low-value code. If velocity is all that matters, the team may split meaningless tickets. If defect count is punished, people may hide defects or avoid difficult modules.
This is not a character flaw. Systems respond to incentives.
Use metrics with guardrails:
- Use them for team improvement, not individual shaming.
- Read multiple metrics together, not one number as a verdict.
- Look at trends, not just one point in time.
- State which decision the metric supports.
- Recheck whether the metric is being gamed.
Better Questions Beat Better Charts
Metrics matter because of the questions they enable:
- Why is review waiting time increasing?
- Which modules have both high churn and high defects?
- Which release types are most often rolled back?
- Are test failures mostly from flaky tests?
- Where do new engineers get stuck in the codebase?
When a metric produces better engineering discussion, it is useful. Otherwise even a beautiful dashboard is noise.