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.
Why Earlier Is Usually Cheaper
It is widely believed that a defect costs more to fix the later it is found. The general direction is well supported: a defect found in design or code review can be fixed by the author in minutes, while one found in production may need diagnosis, a hotfix, customer communication, and cleanup of bad data. The precise multipliers quoted in the literature vary widely and some are disputed, so treat any specific ratio as illustrative.
Measure your own curve. For a sample of defects, record the stage where they were introduced, the stage where they were found, and the effort to fix them. Even rough numbers show where earlier checks would pay off.
Prevention has layers. Clear requirements and acceptance criteria, design discussions, coding standards, static analysis, automated tests, peer review, and monitoring each catch different kinds of defects. No layer is perfect, so the layers work together, as described in the guide on layers of defect prevention above.
Fix causes, not only instances. When a class of defect recurs, such as null handling or timezone errors, add a check, a lint rule, a library, or a design pattern that prevents the whole class.
Making Code Review Work in Practice
Code review works when it is small, fast, and focused on what people are good at: understanding intent, design, and risk. It fails when it becomes a bottleneck or a place for style arguments.
- Keep changes small. Review effectiveness drops as the size grows. Changes of a few hundred lines or fewer get more careful attention than large ones.
- Automate the routine. Formatters, linters, and tests should handle style and simple errors, leaving reviewers to consider logic, design, security, and maintainability.
- Use a short checklist for what to look for: correctness, error handling, tests, security concerns, readability, and effects on other parts.
- Review promptly. A waiting pull request stalls work and encourages big batches. Set an expectation for turnaround, for example within one working day.
- Be kind and specific. Comment on the code, not the person; distinguish must-fix from suggestions; and explain why.
- Share the load. Spread reviews across the team so that knowledge spreads and no one becomes a bottleneck.
| Measure | Use with care |
|---|---|
| Review turnaround time | Shows flow; do not push it so hard that reviews become superficial |
| Defects found in review vs later | Shows effectiveness; needs consistent defect recording |
| Size of changes | Shows batch size; smaller is usually better |
| Escaped defects per change | Outcome; track by trend, not by person |
Pitfalls. Rubber-stamp approvals; reviewers who only check style; blame when defects escape; large changes merged because review is slow; and measuring individuals by the number of comments. See the Defect Removal Efficiency Calculator, the Quality Gates Guide, and the Mistake-Proofing Guide. Figures in the examples are illustrative.
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.