Code Inspection

Code inspection is a formal, structured technique for static defect detection developed by Michael Fagan at IBM in the 1970s. Unlike informal code review — where a colleague reads a diff and leaves comments — inspection follows a defined process with assigned roles, entry and exit criteria, preparation requirements, and recorded defect logs. Fagan’s original IBM data showed inspections removing 60-90% of defects before testing, at a fraction of the cost of finding those defects in production. Inspections became the most studied and validated defect-detection method in software engineering history.

The key insight that makes inspections more effective than casual review is preparation and structure. Reviewers study the material independently before the meeting, using a checklist of historically common error types. The meeting itself focuses on defect identification, not discussion or solutions — a discipline that keeps inspections short and productive. Fixes happen after, by the author, and are verified in a re-inspection or follow-up.

The Fagan Inspection Process

Roles

Author — wrote the artifact under inspection. Presents but does not defend; their job is to explain, not argue.

Moderator — runs the meeting, enforces process, ensures defects are logged without derailing into solution discussions. Does not participate in defect finding.

Inspector(s) — examine the artifact independently before the meeting, arrive with a prepared list of potential defects.

Reader — paraphrases the code section by section, driving the team’s attention through the artifact systematically.

Phases

1. Planning — moderator confirms the artifact meets entry criteria (compiles, has tests, author has self-reviewed)
2. Overview — author explains the context and intent (skipped for experienced teams or small artifacts)
3. Preparation — inspectors study the artifact independently using a checklist; typically 1-2 hours per 200 lines
4. Inspection meeting — reader walks through; inspectors raise defects; moderator logs them; target: under 2 hours
5. Rework — author fixes identified defects
6. Follow-up — moderator verifies fixes; re-inspection only for major defects or high defect density

Entry Criteria

• Code compiles without errors
• Static analysis has been run (no blocking issues)
• Author has self-reviewed against the checklist
• Adequate preparation time was scheduled

Inspection vs. Code Review

	Code Review	Code Inspection
Structure	Informal	Formal with defined roles
Timing	After PR submission	Scheduled with prep time
Preparation	Optional	Required (1-2 hrs)
Focus	Correctness + style	Defect identification only
Data	Rarely tracked	Defect log maintained
Cost	Lower per review	Higher per artifact
Defect yield	20-40%	60-90%

Modern teams typically use lightweight code reviews for routine changes and reserve formal inspection for high-risk components: security modules, financial calculations, safety-critical code paths.

Checklists in Inspection

Inspection checklists codify recurring defect types for a given language or domain. Common categories:

• Initialization: variables used before assignment, off-by-one in array bounds
• Logic: incorrect boolean operators, missing else cases, inverted conditions
• Control flow: unreachable code, missing return, infinite loop conditions
• Error handling: unchecked return values, swallowed exceptions
• Concurrency: race conditions, missing locks, deadlock potential

Checklists should be maintained — items that are never found become noise; newly discovered defect patterns should be added.

Key Concepts

• Inspection is formal defect detection with defined roles, preparation, and exit criteria
• The inspection meeting finds defects; it does not fix them — discipline that keeps meetings productive
• Independent preparation before the meeting is the primary driver of inspection’s superior defect yield
• Checklists encode historically common defect patterns for a given codebase or language
• Track defect density (defects per 1000 lines) to identify high-risk modules and guide testing effort

Related Concepts

• Code Reviews — the lightweight, informal variant used for routine changes
• Code Metrics — defect density from inspections is itself a metric for module risk
• Pair Programming — continuous review that shares some of inspection’s defect-detection value

References

• Fagan, M. (1976). Design and Code Inspections to Reduce Errors in Program Development. IBM Systems Journal, 15(3).
• Gilb, T., & Graham, D. (1993). Software Inspection. Addison-Wesley.
• Wiegers, K. (2002). Peer Reviews in Software: A Practical Guide. Addison-Wesley.