Lesson239 words
Metrics and queries for development
Metrics and queries for development
What is worth measuring
| Metric | Signals |
|---|---|
| Pull request cycle time | How long review takes — usually the biggest hidden delay |
| PR size | Large PRs get worse review; the correlation is strong |
Build failure rate on main | Whether the trunk is healthy |
| Time to first review | Whether work sits unattended |
| Code churn | Repeated rewriting of the same area |
Review latency is usually the bottleneck
Teams instinctively optimise build speed, which is visible on a dashboard. Time-to-first-review is often several times larger and rarely displayed — a two-minute build behind an eleven-hour review wait is not a fast pipeline.
Metrics that mislead
| Metric | Why it fails |
|---|---|
| Lines of code | Rewards volume; deleting code is usually good |
| Commits per developer | Rewards splitting commits |
| Individual velocity | Punishes helping colleagues |
The common thread: anything measuring an individual's output rather than the system's flow degrades collaboration, because helping someone else always lowers your own number.
Churn
High churn in one area means the design is not settled there. It is a prompt to investigate — the answer might be an unclear requirement, a missing abstraction, or a genuinely volatile domain — not a number to drive down.
Primary sources