Software quality metrics describe the code and the product itself: how many bugs it has, how much of it is tested, how hard it is to follow, how expensive it will be to change next quarter. Defect density, test coverage, cyclomatic complexity, and maintainability all answer some version of that question. A metric that clocks how fast you ship answers a different one, and conflating the two is a common mistake in how teams talk about quality.
What are software quality metrics?
They're measures of the artifact itself, distinct from the delivery-speed measures of the pipeline that produces it: defect counts, test coverage percentages, complexity scores, and maintainability ratings that describe the state of a codebase or a product at a point in time. That definition deliberately excludes deployment frequency, lead time for changes, change failure rate, and recovery time, the metrics that describe how a team ships rather than what it ships. Those four live under a different framework, DORA, with its own history and its own benchmarks.
The ISO/IEC 25010 quality characteristics
ISO/IEC 25010, revised in 2023, defines nine characteristics that make up a software product's quality model. Sonar's rundown of the standard lists them as functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, and safety. The standard's own reference site confirms the same nine sit inside "the product quality model defined in ISO/IEC 25010."
Every metric in the next section maps back to one or more of those nine characteristics. Defect density and test coverage speak to reliability. Cyclomatic complexity, cognitive complexity, and maintainability all speak to maintainability itself, the ISO characteristic that the metric borrows its name from.
The core code-quality metrics engineering teams track
Defect density
Defect density counts bugs against the size of the codebase that produced them. LANSA's guide to the formula divides total defects by codebase size in thousands of lines of code (KLOC). There's no widely accepted benchmark for what that number should be, so there's no universal "good" defect density to hit. A number that's healthy on a payments system with a large, safety-critical surface looks nothing like a healthy number on an internal tool three engineers maintain part time.
Escaped defects (customer-reported bugs)
Escaped defects catch what testing missed. getdx's list of software quality metrics defines the metric simply, counting "how many problems users find after releasing the software." Defect density only counts what got caught before release; escaped defects tell you how much slipped past every gate you already had in place.
Test coverage
SonarQube's own metric definitions describe coverage as "a mix of line coverage and condition coverage," built to answer "how much of the source code has been covered by unit tests." A high percentage on its own says nothing about which lines are covered. A file sitting at 95% can still ship a production bug if the untested 5% is the branch that handles a rare input, and coverage alone won't flag that without checking it against complexity or churn.
Cyclomatic complexity
Cyclomatic complexity has a name and a date attached to it. IBM's explainer on the metric attributes it to Thomas McCabe's 1976 paper, "A complexity measure," and gives the formula as M = E - N + 2P, where E is edges, N is nodes, and P is the number of connected components in a function's control-flow graph. The formula matters less in practice than the threshold: the same explainer notes that the common practice among most engineering groups is setting a maximum value of M≤10 per function in CI/CD pipelines, enforced automatically rather than checked by hand after the fact.
Cognitive complexity
Cyclomatic complexity counts paths through a function. Cognitive complexity measures something else entirely, defined in the same SonarQube documentation cited above as "a qualification of how hard it is to understand the code's control flow." A function can carry a high path count and still read cleanly, or a low path count and still confuse the next engineer who opens it. Track both, because a function that passes on one score can still fail the other.
Maintainability rating
SonarQube's maintainability rating scale grades a codebase A through E based on the ratio of "technical debt / (cost to develop one line of code × number of lines of code)": A sits at 5% or under, B runs from 5% to under 10%, C from 10% to under 20%, D from 20% to under 50%, and E covers anything at 50% or above. That ratio is a technical-debt score wearing a quality-metric label, worth remembering the next time someone reports it without the number underneath.
Software quality metrics vs. DORA metrics: what's the difference?
Quality metrics measure the artifact. DORA measures the process that produces it. The delivery-speed metrics DORA already tracks live in their own framework with their own definitions. Nothing above tells you how often a team ships or how fast it recovers from a bad release, and nothing in a DORA guide tells you whether the code itself is well tested or easy to change.
Some popular quality-metric guides blur that line anyway. getdx's list explicitly labels MTTR and lead time for changes as DORA metrics, then places them alongside defect density and test coverage in the same rundown. LANSA's guide lists the same delivery-speed figures in its quality-metrics list without naming DORA at all, leaving a reader to assume they belong there. Read one of those lists uncritically and a team ends up tracking lead time as a quality score, rewarding a fast, buggy release just as much as a fast, clean one.
How to start tracking software quality metrics on a distributed team
1. Wire a static-analysis tool into CI
Test coverage, cyclomatic complexity, and maintainability ratings all come from the same class of tool: a static analyzer running inside the build, checked automatically on every merge instead of updated by hand once a week. If the pipeline doesn't already emit these numbers on every merge, that's the real first step, ahead of any argument about thresholds.
2. Set thresholds before a crisis forces one
A complexity ceiling decided the week after a production incident looks like it's aimed at whoever caused the incident, and it gets resented accordingly. Set the M≤10 complexity gate, the maintainability floor, and the coverage target before there's a specific pull request or person to blame. A written review policy with a PR size ceiling does the same job for review turnaround, and both work better decided in calm weather than in a postmortem.
3. Decide who owns a complexity or coverage regression
A number sliding the wrong way for one sprint usually isn't worth a fire drill. A number sliding the wrong way for three sprints running needs an owner: someone whose job is deciding whether it's real drift or noise. It's the same discipline behind a debt register with a named owner per item: a metric nobody owns degrades the way unowned debt does, quietly, until fixing it costs a lot more than watching it would have.
4. Track in-house and externally-sourced code separately until you trust the pipeline
On a team where part of the codebase comes from a nearshore engineer, an augmented senior, or an AI assistant, blending every number together erases the ability to tell where a complexity spike or coverage gap actually started. HighCircl's four-stage vetting process for augmented engineers ends with a live technical session focused on architectural reasoning. Split the metrics by source for the first few months of an engagement, then merge them once the new code's numbers hold up the same as the rest of the codebase. What happens to delivery stability once AI writes more of the diff is the same question asked from the delivery side, and it's worth reading next to this list rather than in place of it.
Frequently asked questions
What are software quality metrics?
Measures of the software itself rather than how fast a team ships it: defect density, escaped defects, test coverage, cyclomatic complexity, cognitive complexity, and maintainability ratings all describe the state of the code or the product, distinct from delivery-speed metrics like deployment frequency.
What's a good defect density?
There's no widely accepted benchmark you can cite here. LANSA's formula, total defects divided by thousands of lines of code, gives you a number worth tracking over time, but what counts as good depends heavily on the codebase: a payments system and an internal reporting tool don't share a bar.
Is cyclomatic complexity the same as cognitive complexity?
No. Cyclomatic complexity counts the number of independent paths through a function's control flow, the measure McCabe defined in 1976. Cognitive complexity measures something else, how hard the code is for a person to follow, and a function can score high on one and low on the other.
Are DORA metrics the same as software quality metrics?
No. DORA metrics measure delivery speed and stability. Software quality metrics measure the code and the product itself.