Code quality and technical debt

Defect density

Also known as Defect density, Defect density in software engineering

By WeavePublished 1 min read

Definition

The number of confirmed defects relative to a defined amount of software or change.

What it means

Defect density normalizes confirmed defects by a unit such as changed lines, function points, modules, or delivered features. It can support comparisons within a stable process, but the denominator and defect discovery window must remain consistent. Use it to ask where defects concentrate, not to rank people.

Example

A team compares post-release defects per thousand changed lines across two services. One service has a higher rate, so engineers inspect its review path, test boundaries, and release exposure instead of assuming individual failure.

Limitations

Counts depend on reporting habits, severity rules, observability, and time to discovery. A low density may reflect under-reporting or a young release. Lines of code are a weak proxy for behavior and should not be treated as product value.

How to use the signal

Keep severity and discovery windows visible so the normalized value does not hide a small number of consequential failures.

Weave can help relate defect-density changes to review, deployment, and rework signals. Keep defect classification in the issue or quality system and document the observation window.

How this relates to Weave

Weave can help relate defect-density changes to review, deployment, and rework signals. Keep defect classification in the issue or quality system and document the observation window.

Explore Engineering intelligence

Sources and further reading

  1. SonarSource code metrics and analysis documentation