The cheapest defect is the one never written, and the next cheapest is the one found right where it was introduced. Software quality improves when a team stops relying on late testing and adds layers of prevention and early detection.
This guide covers those layers, how to run effective code reviews, how to measure defect removal efficiency, and a worked example in which a review checklist built from production defects raises DRE and cuts the cost of fixing defects.
Before You Start
Why Preventing and Finding Defects Early Matters
Late Defects Cost More
A defect found in a design review is a conversation. The same defect found in production is an incident, a patch, and possibly a customer complaint.
Testing Alone Is Not Enough
Tests find defects, but they are a late and partial filter. Reviews, standards, and tooling prevent many defects from being introduced at all.
Rework Is Invisible Waste
Fixing and re-testing consumes engineer time that is rarely tracked. Counting defects by stage makes it visible.
Quality Enables Speed
Teams that spend less time on rework and firefighting can deliver more, and more predictably.
Layers of Defect Prevention and Removal
| Layer | What it does | Examples |
|---|---|---|
| Prevent | Make defects hard to introduce | Clear requirements, design reviews, coding standards, type systems, templates, pairing |
| Detect early | Find defects near where they were introduced | Code review, static analysis, linters, unit tests, secret and dependency scanning |
| Detect at integration | Find defects that appear when parts combine | Integration and system tests, contract tests, staging checks |
| Contain in production | Limit the impact of what escapes | Feature flags, canary releases, monitoring, fast rollback |
| Learn | Prevent recurrence | Root cause analysis, blameless postmortems, updated checklists |
Effective Code Review
- Keep changes small. Reviewers find more problems in a 200-line change than a 2,000-line one, and turn it around faster.
- Use a checklist drawn from your own defect history, such as error handling, input validation, concurrency, and logging, so reviewers look for what actually goes wrong.
- Automate the mechanical. Let linters, formatters, and static analysis handle style and common bug patterns, so people review design and logic.
- Review for understanding. If the reviewer cannot explain what the change does, it needs a clearer description or tests.
- Measure turnaround. Long review queues are waiting waste and encourage large batches. See Flow Metrics and WIP Limits.
Reviews find some kinds of defects well, such as maintainability and logic errors, and others poorly, such as performance under load. Combine them with testing and monitoring.
Defect Removal Efficiency
Defect removal efficiency (DRE) is the percentage of all defects that were found before release: DRE = defects found before release / (defects found before release + defects found after release). Capers Jones and others have reported DRE for many projects; typical values vary widely by organization and method, so the useful comparison is with your own history. You can also calculate phase containment, the share of defects caught in the same stage where they were introduced.
Worked Example: Adding a Review Checklist
A team counts defects by the stage where they were found over a release cycle. The figures and unit costs are illustrative.
| Item | Before |
|---|---|
| Total defects | 140 |
| Found before release | 125 |
| Escaped to production | 15 |
| DRE | 125 / 140 = 89.3% |
| Cost of fixing all defects | 12 × $50 + 38 × $80 + 45 × $120 + 30 × $300 + 15 × $1,500 = $40,540 |
The team introduces a code review checklist built from the last release's production defects and adds a lightweight design review for changes above a size threshold. On the next release, the same 140 defects were introduced, but they were found earlier:
| Stage | Before | After |
|---|---|---|
| Design review | 12 | 14 |
| Code review | 38 | 52 |
| Unit tests | 45 | 44 |
| System tests | 30 | 21 |
| Production | 15 | 9 |
| Total cost | $40,540 | $29,940 |
DRE rises from 89.3% to 131 / 140 = 93.6%, and the cost of fixing defects falls by $10,600. The improvement did not come from testing harder. It came from finding the same defects earlier and from the checklist directing attention where defects had actually occurred. Keep in mind that the number of defects introduced is rarely the same from release to release, so treat a single before-and-after comparison cautiously and track DRE over several releases.
Enter your own stage counts and costs in the Defect Removal Efficiency Calculator.
Self-Assessment Questions
- Do we record the stage where each defect was found, and where it was introduced?
- Do our code review checklists come from our own defect history?
- Are review queues short, and are changes small?
- Do we know our DRE, and how it trends over releases?
- Do we run root cause analysis on production escapes and update our practices?
Common Mistakes
Relying on Testing Alone
Late testing is expensive and partial. Add reviews, static analysis, and design attention earlier.
Treating Reviews as Style Police
If reviews focus on formatting, automate it and spend human time on logic and design.
Not Recording Where Defects Were Introduced
Without it, you cannot tell whether earlier stages are getting better.
Using Defect Counts to Judge Individuals
It encourages hiding defects or arguing over classification. Use the data to improve the process.
Defect Prevention and Code Review: Frequently Asked Questions
What is defect removal efficiency?
Defect removal efficiency (DRE) is the percentage of all defects found before release. It is calculated as defects found before release divided by the total of defects found before and after release. It shows how well a team's combined reviews and tests filter out defects before customers meet them.
Are code reviews worth the time?
Generally yes, when they are small, use checklists based on the team's own defect history, and are combined with automation for mechanical checks. Reviews find defects early, spread knowledge, and improve design, but they should be measured for turnaround so they do not become a bottleneck.
Is it true that defects cost more the later they are found?
It is a widely repeated rule that fixing a defect later costs more, and the cost multipliers vary considerably between studies and contexts. The safest approach is to measure the cost in your own environment, as the worked example does with assumed values, and use it to decide where to invest in earlier detection.
Sources and Further Reading
- Capers Jones, Applied Software Measurement and Software Engineering Best Practices, on defect removal efficiency.
- Steve McConnell, Code Complete, chapters on quality assurance and reviews.
- Karl Wiegers, Peer Reviews in Software.
- ASQ Certified Software Quality Engineer Body of Knowledge.