Software development metrics: the full catalog, organized by lens
Updated
This is the comprehensive, vendor-neutral catalog of software development metrics — every durable measure worth tracking, organized by the lens that asks for it: delivery, flow, reliability, quality, security, technical debt, developer experience, compliance, finance, and the board.
Read it as a menu, not a mandate. No team should track all of these. Pick a few per lens, pair each with a counter-metric, and read the blind-spot column as closely as the definition, because that is where the number lies. Every metric here is real and every one bends under Goodhart's law once it becomes a target, so the catalog exists to help you choose deliberately rather than to hand you a score.
How to use this catalog
The catalog is organized by lens — the vantage point from which someone asks whether engineering is healthy. A delivery lead, a site-reliability engineer, a CFO, and a board risk committee each want different numbers, so every lens below collects the metrics that answer its question. Each table gives four things per metric: what it measures, the blind spot or the way it is gamed, and the standard or source it comes from.
Use it the way you would a menu, not a checklist. Pick a few metrics per lens that fit the decision in front of you; more instrumentation is not more insight. Watch the blind-spot column as carefully as the definition. And hold every metric to Goodhart's law: as soon as a measure becomes a target, it stops measuring what you cared about. Pair each metric with a counter-metric, prefer trends and distributions over single absolutes, and never grade individuals with numbers built to describe systems.
Delivery & Throughput — DORA
The four DORA keys — two throughput, two stability — plus the reliability and Accelerate companions that keep them honest.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Deployment Frequency | How often the org successfully releases changes to production. | Rewards frequent trivial/no-op deploys and says nothing about batch size or value; gamed by splitting one release into many. | DORA (Accelerate / State of DevOps) |
| Lead Time for Changes | Elapsed time from code committed to that code running in production. | Clock starts at first commit, so it ignores backlog, design, and review-queue wait — and shrinks if you just commit later. | DORA (Accelerate / State of DevOps) |
| Change Failure Rate | Share of deployments that cause a production failure needing remediation (rollback, hotfix, patch). | Depends on self-defined 'failure'; teams lower it by re-labeling incidents or narrowing what counts. | DORA (Accelerate / State of DevOps) |
| Failed Deployment Recovery Time (Time to Restore / MTTR) | How long to restore service after a failed deployment or incident. | Averages hide catastrophic long-tail outages, and 'restored' can mean a feature flag off without root-cause fix. | DORA (Accelerate / State of DevOps) |
| Reliability | Degree to which operations meet their reliability targets — availability, latency, performance (SLO attainment). | Self-assessed and only as honest as the SLO; loosely set targets are always 'met.' | DORA (5th key, 2021+) |
| Batch Size | Amount of work shipped per deployment; smaller batches move faster and fail smaller. | No standard unit, so it is gamed by counting differently and ignores the complexity or risk of what shipped. | Accelerate / Lean Software Development |
| Rework Rate (% Unplanned Work) | Proportion of team capacity spent on firefighting and rework versus new value. | Relies on honest time categorization; 'rework' vs 'iteration' is subjective and easily miscoded. | Accelerate (DORA) |
| Deployment Pain | How much fear, stress, and manual toil a release imposes on the team. | Subjective survey sentiment, not a hard metric; suppressed by social desirability and survey fatigue. | Accelerate (DORA) |
| Mean Time to Detect (MTTD) | Elapsed time between a failure beginning and the team actually noticing it. | Only counts incidents you eventually detect; silent failures on unmonitored surfaces never enter the number. | Google SRE |
| Mean Time Between Failures (MTBF) | Average production uptime between failures — a stability/reliability companion to recovery time. | An average that flatters systems with rare-but-severe outages and ignores blast radius and severity. | Reliability engineering / Google SRE |
Flow & Work Management
How work actually moves through the system — the speed, volume, and idle time of items in a value stream, as defined by the Kanban Method and the Flow Framework.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Cycle Time | Elapsed time a work item spends actively in progress, from start to done. | An average hides the tail; starting the clock late or excluding wait states flatters it and says nothing about whether the right thing shipped. | Kanban Method (Anderson) / Actionable Agile Metrics (Vacanti) |
| Lead Time (Customer Lead Time) | Time from a request being accepted/committed to its delivery to the customer. | Gameable by delaying commitment so the queue time before 'accept' stays invisible. | Flow Framework (Kersten) / Kanban Method |
| Work in Progress (WIP) | Count of items started but not yet finished at a point in time. | A raw count ignores item size and is gamed by splitting work or parking items as 'blocked' to hide them. | Kanban Method (Anderson) / Little's Law |
| Throughput | Number of work items completed per unit of time. | Counts items, not value; inflated by slicing work thin or closing trivial tickets. | Kanban Method / Actionable Agile Metrics (Vacanti) |
| Flow Efficiency | Ratio of active (value-add) time to total flow time (active + waiting). | Depends entirely on honestly logging wait states; teams without 'blocked/waiting' columns report a falsely high number. | Lean / Kanban (Vacanti; Modig & Åhlström, 'This is Lean') |
| Work Item Age (Aging WIP) | Elapsed time an in-progress item has been open right now, before it is finished. | A leading signal only if watched daily; ignores not-yet-started work and can be reset by closing-and-reopening. | Kanban Method / Actionable Agile Metrics (Vacanti) |
| Queue Time / Wait Time | Portion of flow time an item sits idle in a queue or blocked, waiting on a downstream step. | Invisible unless queues are explicitly modeled on the board; easily absorbed into 'in progress.' | Lean / Kanban Method |
| Flow Velocity | Number of flow items (features, defects, risks, debt) completed per period in a value stream. | A productivity proxy that ignores item value and can rise while the wrong flow-item types dominate. | Flow Framework (Kersten, 'Project to Product') |
| Flow Time | Total elapsed time from when a flow item enters the value stream to release, including wait time. | An aggregate that masks which stage is the bottleneck; skewed by outliers unless shown as a distribution. | Flow Framework (Kersten) |
| Flow Load | Number of flow items actively in progress in a value stream (WIP at the value-stream level). | High load lengthens flow time but doesn't reveal the cause; gameable by re-tagging active items as 'waiting.' | Flow Framework (Kersten) |
| Flow Distribution | Proportion of completed flow items across the four types — features, defects, risk, debt — over a period. | A balance metric with no universally 'correct' mix; a target can be hit by mislabeling item types. | Flow Framework (Kersten) |
| Cumulative Flow Diagram (CFD) | Arrivals vs. departures across workflow states over time, visualizing WIP, approximate cycle time, and queue growth. | Only as honest as the column mapping; widening bands can be masked by redrawing states or batch status updates. | Kanban Method (Anderson) / Actionable Agile |
Reliability & SRE
The Google SRE stack for measuring whether a service is reliable enough — and detecting, surviving, and learning from the times it isn't.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Service Level Indicator (SLI) | A quantitative signal of service health, usually the ratio of good events to valid events (availability, latency, correctness, throughput). | Picking a flattering measurement point (server-side vs. user-perceived) and aggregate ratios hide the tail of users actually in pain. | Google SRE (SRE Book / Workbook) |
| Service Level Objective (SLO) | The target threshold an SLI must hold over a rolling window — the internal definition of 'reliable enough.' | Set too loose it's meaningless, and a long averaging window lets a short severe outage disappear; 'improved' by loosening the target rather than the service. | Google SRE |
| Service Level Agreement (SLA) | The externally committed reliability level carrying contractual or financial consequences if breached. | Deliberately looser than the internal SLO and measures only refund liability, not user happiness; narrowed by excluded maintenance windows and definitions. | Google SRE / contractual |
| Error Budget | The permitted amount of unreliability (1 − SLO) available to 'spend' on releases, experiments, and failures. | A full budget can license reckless shipping; scoped per-service it ignores correlated cross-service user journeys, and periodic resets mask chronic issues. | Google SRE |
| Error Budget Burn Rate | How fast the error budget is being consumed relative to the window; a sustained rate above 1x exhausts it before the window ends. | A single-window threshold alerts either too slowly or too noisily (needs multi-window, multi-burn-rate); gamed by lengthening the measurement window. | Google SRE Workbook |
| Availability / Uptime | The fraction of time or of requests during which the service is functioning correctly (time-based or request-based). | High 'nines' can coexist with a broken critical feature; time-based uptime misses partial degradation and per-user request failures. | Google SRE |
| Latency (p50/p95/p99) | The response-time distribution of requests — a Golden Signal — measured separately for successful vs. failed requests. | Means hide the tail and even p99 ignores the worst users, who may be the largest accounts; gamed by excluding timeouts/errors from the sample. | Google SRE Four Golden Signals |
| Saturation | How full the most constrained resource is (CPU, memory, I/O, connection pool, queue depth) — a Golden Signal and leading indicator. | Utilization targets miss the latency cliff that hits well before 100%; watching the wrong bottleneck lets a hidden resource saturate unseen. | Google SRE Four Golden Signals |
| Mean Time to Detect (MTTD) | Average elapsed time from incident onset to detection or alert firing. | Counts only incidents eventually detected (survivorship) and a mean hides bimodal behavior; 'fast' detection can just mean a flood of noisy alerts. | Google SRE / incident management |
| Mean Time to Restore (MTTR) | Average time from detection to service restoration for an incident. | An average over wildly heterogeneous incidents is statistically weak and excludes undetected outages; gamed by closing incidents early or reclassifying severity. | Google SRE / ITIL |
| Mean Time Between Failures (MTBF) | Average operational time between failures — a stability / reliability measure of how often the service breaks. | Assumes a roughly constant failure rate; a high MTBF with rare catastrophic failures still fails users, and narrowing the definition of 'failure' inflates it. | Reliability engineering / Google SRE |
| Toil | The share of operational effort that is manual, repetitive, automatable, tactical, and scales with load without enduring value. | Self-reported and subjective; 'interesting' manual work gets excused, and reducing measured toil can just shift it to an unmeasured team. | Google SRE |
| Incident Count & Severity (SEV) | The number of incidents bucketed by severity level (SEV1/2/3) over a period. | Severity is human-assigned and quietly downgraded to dodge scrutiny; raw counts penalize good detection and reporting culture and ignore impact duration. | Google SRE incident management |
Code Quality & Testing
Metrics that gauge how much defect risk survives into production and how much of it the test and review net actually catches.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Change Failure Rate | Share of production releases that degrade service and require a hotfix, rollback, or patch. | "Failure" is self-defined; batching releases or under-reporting incidents deflates it without improving quality. | DORA / Accelerate (Google Cloud) |
| Defect Escape Rate (Escaped/Production Defects) | Defects first discovered in production versus total defects found across all phases. | Only counts bugs you detect and attribute; silent failures and unreported issues never enter the numerator. | ISTQB defect metrics / phase-containment |
| Defect Removal Efficiency (DRE) | Percentage of all defects removed before release (pre-release finds / (pre + post-release)). | Denominator only holds defects eventually found, so it reads high until latent bugs surface later. | Capers Jones / IFPUG |
| Defect Density | Confirmed defects normalized by size, per KLOC or per function point. | Normalizing by lines rewards verbose code; ignores severity and where defects cluster. | IEEE Std 982.1 / ISO/IEC 25023 (SQuaRE) |
| Code Coverage (Statement/Branch) | Proportion of code paths executed by the automated test suite. | Executing a line is not asserting its behavior; high coverage with weak assertions is coverage theater. | ISO/IEC/IEEE 29119 / ISTQB |
| Mutation Score | Percentage of injected faults (mutants) that the test suite detects and kills. | Equivalent mutants distort the score; cost pushes teams to sample and cherry-pick easy operators. | ISO/IEC/IEEE 29119 (DeMillo, Lipton & Sayward) |
| Flaky-Test Rate | Share of tests that pass and fail non-deterministically on identical code. | Auto-retry and quarantine hide flakes instead of fixing them, masking real race conditions. | Google Engineering Practices / Testing Blog |
| Review Defect-Escape (Inspection Effectiveness) | Defects that pass code review and surface later versus those caught during review. | Requires tracing prod bugs back to the reviewed diff; rubber-stamp approvals still count as "reviewed." | Fagan Inspection (IBM) / SmartBear |
| Cyclomatic Complexity | Number of linearly independent execution paths through a code unit. | Splitting functions lowers per-unit numbers without cutting real complexity; weak correlation with defects. | McCabe (1976) / ISO/IEC 25023 |
| Technical Debt Ratio | Estimated remediation cost divided by the cost to build the code. | Entirely defined by the chosen ruleset; loosen the rules and the ratio drops with no code change. | SQALE method (SonarSource) |
| Maintainability Index | Composite 0-100 score from complexity, Halstead volume, and lines of code. | Opaque aggregate with arbitrary thresholds; a good score can still hide untested, fragile code. | SEI / Microsoft Visual Studio |
Security Posture
How fast and how completely the organization finds, ages, and closes vulnerabilities — weighted toward what is actually exploited, not just what is counted.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Vulnerability Aging by Severity | Age distribution of open vulnerabilities bucketed by severity (how long criticals/highs have sat unremediated). | Aging by CVSS ignores exploitability/reachability — a stale 'high' on an isolated asset outranks a young exploited 'medium'; gamed by re-scoring severity down. | NIST SP 800-40 Rev.4 (Patch/Vulnerability Management); CISA BOD 22-01 |
| Mean Time to Remediate (MTTR) | Average elapsed time from vulnerability detection to verified fix or mitigation. | The mean hides a long tail of unfixed criticals; gamed by mass-closing trivial lows to pull the average down. | NIST SP 800-40 Rev.4; FIRST vulnerability-management guidance |
| KEV (Known Exploited Vulnerabilities) Exposure | Count and age of vulnerabilities present in the environment that appear on CISA's Known Exploited Vulnerabilities catalog. | KEV lags real-world exploitation and omits un-cataloged zero-days, so 'zero KEV' is not 'not exploited'; gamed by tracking only the KEV subset. | CISA Known Exploited Vulnerabilities Catalog / BOD 22-01 |
| EPSS (Exploit Prediction Scoring System) | Modeled probability that a given CVE will be exploited in the wild in the near term, used to rank remediation. | It is a population-level probability, not a verdict — a low-EPSS bug can still be the one used in a targeted attack. | FIRST EPSS |
| CVSS Base / Environmental Score | Standardized technical severity rating of a vulnerability's exploitability and impact. | Base score strips out environment and reachability; using base without environmental/temporal modifiers overstates or understates real risk. | FIRST CVSS v4.0 |
| Remediation SLA Adherence | Percent of vulnerabilities remediated within the policy-defined window for their severity tier. | Measures conformance to a self-set clock, not risk reduction; gamed by lenient SLAs, clock resets, or granting risk-acceptance exceptions. | NIST SP 800-40 Rev.4; PCI DSS v4.0 Req. 6.3.3 |
| Scan / Asset Coverage | Percent of the asset inventory under authenticated, recurring vulnerability scanning. | Coverage of the known inventory says nothing about shadow IT and unmanaged assets; gamed by shrinking the denominator (what's counted as an asset). | CIS Controls v8, Control 7 (Continuous Vulnerability Management); NIST CSF ID.RA |
| Secret-Leak Rate | Rate/count of credentials, keys, and tokens detected in source, logs, images, or repos. | Fully dependent on detector pattern coverage — misses novel/encoded secret formats; gamed by allowlisting or suppressing findings rather than rotating. | OWASP ASVS (Secrets Management); NIST SP 800-53 IA-5 |
| Open Critical / High Finding Count | Number of currently open findings at critical and high severity. | A raw count ignores asset criticality and exploitability; gamed by severity reclassification or bulk risk-acceptance to zero the tally. | OWASP Testing Guide / NIST SP 800-53 RA-5 |
| Vulnerability Recurrence / Reopen Rate | Share of previously remediated vulnerabilities that reappear on later scans. | Doesn't reveal root cause — high recurrence signals fixes without a hardened baseline; gamed by closing tickets without a durable config fix. | NIST SP 800-40 Rev.4; SANS vulnerability-management practice |
| SBOM / Software Composition Coverage | Percent of software with a maintained Software Bill of Materials mapping third-party and transitive components. | SBOM completeness varies and transitive/vendored deps get missed, so component-level exposure stays invisible; gamed by shallow dependency trees. | NIST SSDF (SP 800-218) / NTIA Minimum Elements for an SBOM |
| Mean Time to Detect (MTTD) | Elapsed time from a vulnerability's introduction or disclosure to its first detection by tooling. | Only measures what the tooling can see and is bounded by scan cadence — undetectable exposure never enters the clock. | NIST CSF Detect (DE) function; SANS detection-metrics guidance |
Maintainability & Technical Debt
Signals for how costly the codebase is to change and how much latent rework is accumulating — each is recognized and each is gameable, so read them as a set rather than in isolation.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Cyclomatic Complexity | Count of linearly independent control-flow paths through a function (branch/decision density). | High can be inherent rather than bad; gamed by splitting one method into many that share the same tangled logic. | McCabe (1976); ISO/IEC 25010; SonarQube |
| Cognitive Complexity | How hard code is for a human to read, penalizing nesting and broken control flow (vs. testability). | Language-specific weighting; reducible by hoisting nested logic into helpers without making the whole easier to follow. | SonarSource (Campbell, 2017) |
| Maintainability Index | Normalized composite of Halstead volume, cyclomatic complexity, and LOC rating ease of maintenance. | Aggregation hides which factor is failing; rises simply by shrinking files or adding comments. | Oman & Hagemeister (SEI); Microsoft Visual Studio |
| Code Churn | Volume/frequency of lines added, modified, or deleted in a file over a time window. | Can't distinguish destabilizing thrash from healthy refactoring; inflated by formatters and generated code. | Microsoft Research (Nagappan & Ball) |
| Hotspot (Change Frequency x Complexity) | Files that are both complex and frequently changed — where maintenance effort and defect risk concentrate. | Depends on clean git history; file renames and moves reset the change signal and hide the hotspot. | CodeScene / Tornhill (behavioral code analysis) |
| Duplicated Lines Density | Share of the codebase that is copy-paste/clone-duplicated blocks. | Token-based detectors miss semantic (type-3/4) clones; gamed by trivial edits that break clone matching. | SonarQube; ISO/IEC 25010 |
| Technical Debt Ratio (SQALE) | Estimated remediation cost of quality issues divided by the cost to build the code from scratch. | Remediation estimates are heuristic and cover only rules the analyzer knows; ignores architectural debt. | SQALE method (Letouzey); SonarQube |
| Dependency Freshness (Libyear) | Aggregate time-lag between the versions in use and the latest released versions of dependencies. | Newest isn't always safest or needed; one major-version lag can dominate an otherwise current tree. | Cox et al., "Measuring Dependency Freshness" (ICSE); libyear |
| End-of-Life / Outdated Component Exposure | Count of dependencies past vendor support or flagged outdated in the stack. | EOL is not the same as exploitable and backported fixes may exist; says nothing about whether the component is reachable. | OWASP Top 10 A06:2021 (Vulnerable & Outdated Components); OpenSSF |
| Halstead Volume / Effort | Program size and mental effort derived from counts of distinct and total operators and operands. | Purely lexical — ignores control flow, naming, and readability; verbose-but-simple code scores as hard. | Halstead, "Elements of Software Science" |
| Instability & Distance from Main Sequence | Package coupling health: instability = efferent/(afferent+efferent), plotted against abstractness. | Package-granularity only; a healthy score can still hide tangled classes and cyclic dependencies inside. | Robert C. Martin (Uncle Bob) package-design metrics |
| Legacy Code Share (untested / code age) | Proportion of the codebase lacking automated tests (Feathers' definition) or aging without change. | Coverage can be high yet assert nothing; old, stable code is often the safest, not the most 'legacy'. | Feathers, "Working Effectively with Legacy Code"; CodeScene code-age |
Developer Experience: SPACE + DevEx
How productive, focused, and supported engineers actually feel — measured across SPACE's five dimensions and DevEx's three core loops, never by raw output alone.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Developer Satisfaction / eNPS | Self-reported contentment with tools, team, and work, plus willingness to recommend the org as a place to build. | Survey timing and social-desirability bias inflate scores; an average hides a burned-out or silent minority. | SPACE framework (Forsgren et al., ACM Queue 2021) — Satisfaction & well-being |
| Burnout / Well-being index | Degree of emotional exhaustion and whether the team is operating at a sustainable pace. | Lagging and under-reported — stigma makes people hide burnout until they quit. | SPACE framework — Satisfaction & well-being |
| Engineer retention / voluntary attrition | Whether developers choose to stay, as a downstream signal of overall experience quality. | Very lagging and confounded by comp/market; masks 'quiet quitting' among those who stay. | SPACE framework — Satisfaction & well-being (outcome) |
| Activity volume (commits, PRs, reviews completed) | Count of concrete actions and outputs produced over a period. | Trivially gamed by splitting commits/PRs; rewards busywork and never proves value in isolation. | SPACE framework — Activity |
| Feedback-loop time (build, test, CI, review, deploy) | Speed of getting a response from tools and people after taking an action. | Fast feedback on flaky/noisy signals adds load; averages bury the painful long-tail waits. | DevEx framework (Noda, Storey, Forsgren, Greiler, ACM Queue 2023) — Feedback loops |
| Cognitive load | Mental effort required to understand the codebase, tools, and systems well enough to get work done. | Perceptual and normalized — teams stop noticing chronic friction they've adapted to. | DevEx framework — Cognitive load |
| Flow state / uninterrupted focus time | Frequency and length of deep-work blocks free of interruptions and context switches. | Calendar proxies miss Slack/mental interruptions; gamed by blocking focus time that goes unused. | DevEx framework — Flow state |
| PR / code-review latency (time to first review, time to merge) | Elapsed time from a PR being ready to its first review and to merge. | Rewards rubber-stamp approvals and ignores review depth; gamed with trivially small PRs. | SPACE framework — Efficiency & flow (also a DevEx feedback loop) |
| Time to onboard / time to first meaningful commit | How long a new hire takes to ship their first real change and reach steady productivity. | A token starter task games 'first commit'; it doesn't capture true ramp to autonomy. | DevEx framework — Feedback loops / time-to-productivity |
| Flow Efficiency | Ratio of active work time to total elapsed time, exposing wait and handoff waste. | Depends on accurate work-state tracking; gamed by reclassifying wait states as 'active'. | Flow Framework (Kersten, Project to Product) |
| Toil percentage | Share of engineer time spent on manual, repetitive, automatable operational work. | 'Toil' is a subjective label; gamed by reclassifying it as project work to hit a target. | Google SRE (Site Reliability Engineering) |
| Code-review coverage / collaboration | Breadth of review participation and knowledge sharing (e.g., reviewers per change, bus-factor). | Participation is not quality — produces 'review theater' and drive-by LGTMs. | SPACE framework — Communication & collaboration |
Compliance & Audit
Whether controls exist, are operating, and are being evidenced, reviewed, and remediated on a defensible cadence — the state an auditor or board risk committee asks to see.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Control Coverage % | Share of in-scope risks/requirements mapped to a designed control. | Coverage proves a control exists, not that it operates; a mapped-but-failing control still counts. | COSO Internal Control–Integrated Framework |
| Control Operating Effectiveness Rate | Percent of controls that pass operating-effectiveness testing over the period. | Sample-based — a passing sample doesn't prove the full population, and design vs. operating gaps hide here. | AICPA SOC 2 Trust Services Criteria / PCAOB AS 2201 |
| Evidence Freshness / Staleness | Age of collected control evidence against its required recollection cadence. | A fresh timestamp isn't a valid artifact; automated recollection refreshes the date without re-verifying substance. | ISACA COBIT (Continuous Controls Monitoring) |
| Open Findings & Remediation SLA Adherence | Count of open findings and percent remediated within the committed timeframe by severity. | Gamed by re-rating severity down or closing on paper; the risk stays but leaves the aging bucket. | IIA IPPF (Standards 2060 / 2500) |
| Access Review / Recertification Completion Rate | Percent of periodic user-access reviews completed on schedule by owners. | Rewards completion, not scrutiny — reviewers bulk-approve, so 100% can still leave standing excess access. | NIST SP 800-53 (AC-2 Account Management) / SOX ITGC |
| Segregation-of-Duties (SoD) Conflicts | Number of users holding toxic access combinations that violate the SoD ruleset. | Only as complete as the ruleset; mitigating/compensating controls are asserted to mask residual conflicts. | ISACA / COSO (SOX IT General Controls) |
| Audit Cycle Time | Elapsed time from audit initiation to report issuance. | Faster looks better but is bought by narrowing scope or thinning test depth, not by real efficiency. | IIA IPPF |
| Exception / Waiver Aging | Age and volume of approved policy exceptions and formal risk acceptances. | "Temporary" waivers get silently renewed until indefinite, normalizing accepted risk off the findings list. | ISO/IEC 27001 (risk acceptance / treatment) |
| Policy Acknowledgement / Attestation Rate | Percent of the in-scope workforce who have attested to current policies. | Click-through acknowledgement measures compliance theater, not comprehension or actual behavior change. | COSO (Control Environment) / NIST SP 800-53 (AT, PL) |
| POA&M Overdue Remediation Aging | Count and age of corrective-action items (plan of action & milestones) past their due date. | Repeated milestone date-extensions reset the clock, so true aging and slippage stay hidden. | NIST RMF (SP 800-37) / FISMA |
| Third-Party / Vendor Assessment Coverage | Percent of in-scope vendors with a current, completed risk assessment. | Questionnaire-driven and vendor-self-reported at a point in time; coverage says nothing about live posture. | NIST SP 800-161 (C-SCRM) / ISO/IEC 27001 A.15 |
| Audit Recommendation Implementation Rate | Percent of prior audit recommendations implemented by their agreed date. | "Implemented" is management-asserted; risk-acceptance in lieu of action still counts as closed. | IIA IPPF (Standard 2500 — Monitoring Progress) |
Financial & FinOps (CFO lens)
How a CFO reads engineering: every release, service, and cloud dollar translated into cost of delay, unit economics, capitalization treatment, and the cost of getting it wrong.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Cost of Delay (CoD) | Quantified economic loss per unit time (typically $/week) from delaying delivery of a feature or product. | Rests on speculative future-value estimates, so a sponsor can inflate value to jump the queue. | Reinertsen, 'Principles of Product Development Flow' (adopted by SAFe) |
| WSJF / CD3 (Cost of Delay ÷ job size) | Prioritizes work by cost of delay divided by duration/size to maximize economic value delivered per unit of capacity. | Both numerator and denominator are estimates; shrinking the job-size guess games the ranking upward. | Scaled Agile Framework (SAFe), from Reinertsen's CD3 |
| R&D Capitalization Ratio (capitalize vs. expense) | Share of software-development spend capitalized as an asset versus expensed in the current period. | Aggressive capitalization flatters near-term EBITDA/earnings; the capitalize/expense boundary is judgment-heavy. | US GAAP ASC 350-40 (internal-use software) / IFRS IAS 38 |
| Cloud Unit Economics (unit cost) | Cloud/infrastructure cost per business unit — per transaction, active customer, or order. | A favorable denominator can fall while total spend rises, masking absolute waste. | FinOps Foundation (Unit Economics capability) |
| Cost per Service / Cost per Deployment | Fully-loaded cloud cost attributed to a single service, team, or deployment/release. | Shared and overhead costs are split by arbitrary allocation keys, so the number moves with policy, not reality. | FinOps Foundation (Allocation capability) |
| Cost Allocation Coverage (showback/chargeback) | Percentage of total cloud spend mapped to an accountable owner or cost center. | A large 'unallocated/shared' bucket and loose tagging hygiene hide who actually owns the spend. | FinOps Foundation (Allocation capability) |
| Effective Savings Rate (ESR) | Blended discount off on-demand/list price achieved via commitments, negotiated rates, and optimization. | Rewards rate discounts even on resources that should never have been running at all. | FinOps Foundation (Rate Optimization) |
| Commitment Coverage & Utilization (RI/SP) | Portion of eligible usage covered by reservations/savings plans and how fully those commitments are consumed. | Driving coverage up locks in long-term spend; high utilization can hide an over-provisioned baseline. | FinOps Foundation (Rate Optimization) |
| Cost of Poor Quality (COPQ) / Cost of Quality | Total prevention, appraisal, internal-failure, and external-failure cost attributable to defects. | External-failure costs (lost customers, reputation) are largest and least measured, so reported COPQ understates. | ASQ / Juran, Six Sigma Cost of Quality |
| Failure Demand (cost of rework) | Demand and cost created by not doing something right the first time — rework, reopened tickets, avoidable support. | Hard to cleanly separate failure demand from legitimate value demand, so it is routinely under-counted. | John Seddon / Vanguard Method (Systems Thinking) |
| Total Cost of Ownership (TCO) | Full lifecycle cost of a system — acquisition, run, support, and retirement — not just purchase price. | Omits opportunity cost and soft/indirect costs; long-horizon inputs are easy to bias toward a favored option. | Gartner |
| Budget / Forecast Variance | Actual spend versus budget/forecast, and the accuracy of the cloud-spend forecast over time. | Sandbagging the budget guarantees a favorable variance while masking weak cost discipline. | FinOps Foundation (Forecasting) / standard FP&A |
Board & Executive Risk
The lens a board uses to see aggregate value-at-stake, resilience and recovery readiness, concentration and control-environment posture — risk in dollars and governance terms, not day-to-day delivery.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Value at Risk (VaR) | Maximum expected loss on a position/portfolio over a set horizon at a stated confidence level. | Silent on tail losses beyond the confidence cutoff; gamed by picking a short horizon or a calm lookback window. | Basel Committee on Banking Supervision (market-risk framework) |
| Annualized Loss Expectancy (ALE) | Expected yearly dollar loss from a risk — single loss expectancy x annual rate of occurrence. | Only as good as the guessed frequency/impact inputs; ignores correlated or cascading loss events. | NIST SP 800-30 (Guide for Conducting Risk Assessments) |
| FAIR loss exposure | Cyber/operational risk expressed in dollars as loss event frequency x loss magnitude. | Precise-looking dollar outputs mask wide input uncertainty and can be tuned to a preferred number. | The Open Group — Open FAIR |
| Residual risk (inherent-vs-residual heatmap) | Risk remaining after controls, plotted on a likelihood x impact matrix for the board. | Likelihood/impact scores are subjective; the grid compresses and hides correlated or aggregate exposure. | COSO ERM / ISO 31000 |
| Risk appetite / tolerance breaches | Frequency and size of exposures that exceed board-set appetite and tolerance thresholds. | Appetite statements are often vague or set loosely enough that real breaches rarely register. | COSO ERM (2017, Integrating with Strategy & Performance) |
| Key Risk Indicators (KRIs) | Leading metrics signalling that a specific risk's likelihood or impact is rising. | Only instruments risks someone already anticipated; blind to novel or emerging exposures. | ISACA Risk IT Framework |
| RTO attainment | Whether critical systems/processes are restored within their target recovery time objective. | Usually proven in tabletop/drill conditions that diverge sharply from a real regional outage. | ISO 22301 / NIST SP 800-34 (Contingency Planning) |
| RPO attainment | Actual data-loss window at recovery versus the maximum tolerable data-loss target. | Measured to the last backup timestamp; ignores backup integrity and unverified restores. | ISO 22301 / NIST SP 800-34 |
| Mean Time to Restore (MTTR) | Average time to recover service after a failure or incident. | The average masks catastrophic long-tail outages; gamed by scoping incidents narrowly. | DORA (DevOps Research & Assessment) |
| Concentration risk (HHI) | Dependence of revenue/customers/suppliers on a few counterparties via the Herfindahl-Hirschman Index. | Static snapshot; misses hidden common dependencies (shared cloud, single region) beneath named counterparties. | U.S. DOJ/FTC HHI; Basel concentration-risk guidance |
| Key-person / single-point-of-failure dependency | Exposure to loss of a critical individual or single node with no redundancy. | Captures named roles but misses tacit knowledge; succession plans look complete on paper. | ISO 22301 Business Impact Analysis |
| Benefits realization rate | Share of a strategic initiative's promised business benefits actually delivered post-launch. | Benefits are self-reported and generously attributed; long realization lag lets misses stay hidden. | PMI Standard for Portfolio Management / MSP (Managing Successful Programmes) |
| Control-environment maturity tier | Maturity of the risk and control environment scored against a defined capability scale. | Often self-assessed, and maturity is not effectiveness — a mature process can still fail in practice. | NIST CSF Implementation Tiers / COBIT capability levels |
| Material weaknesses & control deficiencies | Count and severity of internal-control deficiencies over financial reporting, including material weaknesses. | Covers only scoped controls; 'no material weakness' is not 'no risk,' and issues surface after the fact. | SOX Section 404 / PCAOB AS 2201 / COSO Internal Control–Integrated Framework |
Business & Product Outcomes
Metrics that connect engineering delivery to customer and revenue outcomes — how fast value reaches the market, whether shipped features get adopted, and what downtime and defects actually cost the business.
| Metric | What it measures | Blind spot / how it is gamed | Source |
|---|---|---|---|
| Flow Time | Elapsed time from when a work item is committed/started to when it is released to customers (end-to-end lead time to market). | Excludes idea and discovery time before commitment, and is gamed by defining the 'start' state late so the clock begins near delivery. | Flow Framework (Mik Kersten, 'Project to Product') |
| Lead Time for Changes | Time from code committed to that code running in production. | Covers only commit-to-deploy, so slow product/design cycles stay invisible, and dark launches behind feature flags shrink it without delivering value sooner. | DORA (State of DevOps / 'Accelerate') |
| Time to Value (Activation Rate) | How quickly, and what share of, new users reach a defined first-value milestone. | The activation milestone is team-defined and can be set trivially low; hitting it says nothing about durable retention or revenue. | AARRR 'Pirate Metrics' (Dave McClure, 500 Startups) |
| Feature Adoption Rate | Percentage of eligible users who adopt a new feature within a defined window. | Counts first-touch adoption, not sustained value; inflated by forced funnels, modal nags, or counting trivial interactions. | Google HEART framework (Adoption dimension) |
| Engagement / Stickiness (DAU/MAU) | Depth and frequency of product/feature usage, e.g. active-user ratios and sessions per user. | High engagement can signal confusion or friction rather than value, and is a vanity number unless tied to a downstream outcome. | Google HEART framework (Engagement dimension) |
| Major Incident Count | Number of high-priority, business/revenue-impacting incidents over a period. | Depends on a severity classification teams can quietly downgrade, and a raw count ignores each incident's duration and revenue magnitude. | ITIL 4 Incident Management |
| SLO Attainment & Error Budget | Service reliability against a user-centric objective, with remaining error budget gating release velocity. | An SLO met in aggregate hides localized failures for high-value segments, and the SLI/target is team-chosen and can be set loose. | Google SRE (Site Reliability Engineering) |
| Cost of Downtime / Revenue at Risk | Estimated revenue lost per unit of unavailability, linking availability directly to business impact. | A modeled estimate sensitive to assumptions; averaging revenue-per-hour misses peak-vs-off-peak timing and ignores reputational cost. | ITIL Availability Management (business impact analysis) |
| Escaped-Defect Rate / Defect Removal Efficiency (DRE) | Share of defects that reach customers versus those caught before release. | The total-defect denominator is never fully known and user under-reporting flatters it; severity-blind, so a critical bug counts like a cosmetic one. | Defect Removal Efficiency (Capers Jones / IEEE software-quality metrics) |
| Change Failure Rate | Percentage of releases that cause degraded service, a rollback, or a hotfix. | Depends on what gets logged as a failure and can be gamed by shipping smaller/rarer changes; says nothing about failures unrelated to deploys. | DORA (State of DevOps / 'Accelerate') |
| Program Predictability Measure | Ratio of actual business value delivered to planned business value per planning increment (roadmap reliability). | Teams sandbag by planning conservatively, so low commitments guarantee high scores; measures plan adherence, not whether the plan was worth doing. | SAFe (Scaled Agile Framework) |
| Flow Efficiency | Active work time as a proportion of total flow time — how much of lead time is value-add versus waiting. | Requires accurate wait-state tracking, and can look healthy while absolute delivery time to the customer remains poor. | Flow Framework (Flow Metrics) |
Frequently asked questions
What is a software development metric?
A software development metric is a quantitative signal about how a team turns ideas into working, reliable software — its delivery speed, flow, reliability, quality, security, cost, or risk. This catalog groups the durable ones by lens, because no single metric captures engineering health and the useful ones are always read in balanced sets.
How many software development metrics are there, and which should I track?
There is no fixed list; this catalog documents well over a hundred across eleven lenses. You should not track them all. Pick a few per lens that map to a decision you actually make, pair each with a counter-metric, and drop any you cannot act on.
Why does every metric have a blind spot?
Because every metric is a proxy. It stands in for something you care about but cannot measure directly, so there is always a gap between the number and the reality — and that gap is where the metric gets gamed. Naming the blind spot up front is what keeps a measure honest.
What is Goodhart's law and why does it matter here?
Goodhart's law holds that when a measure becomes a target, it stops being a good measure. Tie a bonus or a deadline to any metric in this catalog and people optimize the number rather than the outcome. The defenses are counter-metrics, trends over absolutes, and never scoring individuals with system-level numbers.
Can these metrics measure an individual developer?
No. Almost every metric here describes a system or a team — delivery flow, reliability, cost, risk — and breaks or invites gaming when pinned to one person. The SPACE authors warn against it explicitly. Measure teams and systems, and develop individuals through conversation, not dashboards.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.