Fagan Inspection
Also known as: Fagan method, code inspection, formal review
Fagan Inspection is a formal, structured code review process developed by Michael Fagan at IBM in 1976 that systematically identifies defects before testing. Using defined roles and checklists, Fagan inspections are far more effective at catching bugs than ad-hoc reviews; studies show 70–90% defect detection rate.
Key highlights
- Very high defect detection (70–90%); beats testing alone by 2–3×
- Prevents defects from reaching testing phase; cheap early detection
- Formal roles ensure consistent, unbiased review; checklists catch common mistakes
- Measurable process; defect metrics enable continuous improvement
Intuition
This section is available to Pro members. Upgrade to Pro
How it works
This section is available to Pro members. Upgrade to Pro
When to use it
Use Fagan for critical, complex code (algorithms, security, safety-critical) where defect cost is high. Impractical for exploratory code or trivial changes; cost-benefit favors substantive modules. Essential in aerospace, medical, and financial domains.
Strengths & limitations
- Very high defect detection (70–90%); beats testing alone by 2–3×
- Prevents defects from reaching testing phase; cheap early detection
- Formal roles ensure consistent, unbiased review; checklists catch common mistakes
- Measurable process; defect metrics enable continuous improvement
- Time-consuming: formal inspections take 2–3 hours per module; scales poorly to large teams
- Requires trained moderators and discipline; informal variations lose effectiveness
- Personality conflicts in group settings can suppress honest critique
- False confidence: inspection approval doesn't guarantee absence of subtle logical errors
Common pitfalls
This section is available to Pro members. Upgrade to Pro
Applications
This section is available to Pro members. Upgrade to Pro
Frequently asked
What are the roles in a Fagan inspection meeting?
Moderator (process owner), Author (code writer), Inspector (looks for defects), Reader (explains code), and Recorder (logs findings). Typically 3–5 people; author doesn't inspect own code (bias). Each role has defined responsibilities.
What should inspection checklists include?
Common defect types: undefined variables, array bounds, null pointers, error handling, performance, thread safety. Domain-specific issues: crypto, SQL injection, race conditions. Evolve checklists from past defects found in your project.
How long should an inspection take?
Planning + preparation = 1–2 hours; inspection meeting = 1–2 hours (60–90 min optimal). Larger modules split across multiple meetings. Rate = 100–150 lines of code per hour for thorough inspection.
What happens if inspection finds many defects?
Mark as 'conditional pass' or 'fail'; author reworks code. Choice: re-inspect entire module (formal) or spot-check fixes (lighter). Re-inspection confirms fixes don't introduce new bugs.
Sources
- 1.Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3), 182–211.
- 2.Fagan, M. E. (1986). Advances in software inspections. IEEE Transactions on Software Engineering, SE-12(7), 744–751.
- 3.Gilb, T., & Graham, D. (1993). Software Inspection. Addison-Wesley.ISBN 0201631814
You have read it. What now?
Cite this page
ScholarGate. (2026, June 3). Fagan Inspection. ScholarGate. https://scholargate.app/numerical-methods/fagan-inspection