METRICS & ITERATION · LESSON 06.06intermediate

Software quality metrics.

Defect density, MTTR, change-failure rate — DORA's four.

↳ tl;dr

Quality metrics for software fall into two categories: code quality (defect density, test coverage, code review depth) and operational quality (MTTR, change-failure rate, deployment frequency, lead time). The latter four are the DORA metrics — Google's research-backed indicators of high-performing software orgs.

DORA's four

  • Deployment frequency — how often production deploys happen. High performers: multiple per day.
  • Lead time for changes — commit to production. High performers: under a day.
  • Mean Time To Recover (MTTR) — how long to fix a production incident. High performers: under an hour.
  • Change-failure rate — % of changes that cause a production issue. High performers: 0–15%.

Why DORA's four are powerful

They balance speed (deploy freq, lead time) with stability (MTTR, change-failure rate). A team gaming any one metric regresses the others. Optimizing all four together is what high-performing engineering orgs actually do.

code-level metrics with caution

Defect density (defects per KLOC) and test coverage (% of code under test) are useful internally but easily gamed. A team mandated to hit 90% coverage will write trivial tests; a team mandated to drive defect density to zero will stop logging defects. Use as inputs, not as targets.

What PMs should ask

  • What's our deploy frequency? (Want: not weekly batches.)
  • What's our MTTR for the last 5 incidents? (Want: trending down or stable.)
  • What % of our last 50 deploys caused an incident? (Want: under 15%.)

// sources

Sources cited

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.

// sources

Further reading

  1. [01]
    Rapid Development: Taming Wild Software Schedules

    McConnell, S. · Microsoft Press · 1996 · retrieved 2026-04

    Catalogues 36 'classic mistakes' of software project management.