Two Reviewers, One Diff, Zero Overlap

Two senior engineers review the same pull request. One flags a missing null check. The other spots a race condition in the cleanup path. Neither finds both.

If you had assigned only one reviewer, one of those bugs would have shipped. This is not a skill gap. It is a predictable property of human attention, and Michael Fagan documented it at IBM in 1976.

Fagan was measuring defect detection rates in IBM’s software pipeline. His data showed something uncomfortable: even experienced inspectors caught only a fraction of the total defects the group eventually found. The real value was not in any single person’s expertise. It was in the structured combination of multiple perspectives.

Most teams today do not structure that combination. A senior engineer skims a diff between meetings, notices a style issue, approves, and moves on. The next reviewer does the same. Both miss the off-by-one error that corrupts production data next Tuesday.

Fagan called this unstructured review syndrome. The group has eyes, but no process.

What a Fagan Inspection Actually Is

A Fagan inspection is not a meeting where people read code together and share feelings. It is a formal process with defined roles, entry criteria, and measurable output. Fagan designed it because unstructured reviews wasted time and leaked defects at roughly the same rate as no review at all.

The core insight is role separation. Everyone has exactly one job:

  • The moderator runs the meeting and enforces the rules. They do not inspect.
  • The reader paraphrases the code aloud. This forces the group to confront what the code actually does, not what the author intended.
  • The tester thinks about execution paths, boundary conditions, and coverage gaps.
  • The author answers questions but does not defend the code.

This separation prevents the most common failure mode of group review: the author talking everyone out of their concerns.

When the author is also the explainer, they smooth over ambiguity. “Oh, that variable is always set by the caller.” The group nods. Nobody checks. The reader role exists to break this habit. If the reader cannot paraphrase a function in one sentence, the function is not ready to ship.

Why Checklists Beat Intuition

Fagan also introduced inspection checklists. These are not generic coding standards copied from a style guide. They are tailored to the specific type of artifact being reviewed.

A checklist for a state machine asks: did you handle every transition? A checklist for a resource allocator asks: is every allocation paired with a deallocation on every path?

The checklist exists because human attention is patchy. An expert who has written ten thousand database queries will mentally skip over the BEGIN TRANSACTION block. Their brain autocompletes it as correct. Fagan found that checklist-driven inspectors found defects that intuition-driven reviewers walked past, not because the experts were careless, but because expertise creates blind spots.

Here is a lightweight checklist for a single Python function:

CHECKLIST = [
    "Can a non-author paraphrase what this function does in one sentence?",
    "Does every execution path return or raise predictably?",
    "What happens at the minimum and maximum valid inputs?",
    "What happens at exactly one step past the boundary?",
    "Does the function mutate any argument, closure, or global state?",
    "Is every resource acquired also released on the error path?",
    "If this raises, can the caller distinguish recoverable from fatal?",
]

This is not bureaucracy. It is a forcing function for systematic attention.

Fagan Broke Inspections Into Four Phases, and the Meeting Is the Shortest

A real Fagan inspection has four phases, and the meeting itself is the shortest one.

Preparation. Every inspector reviews the material alone, with the checklist, before the group meets. Fagan found that prepared inspectors found roughly twice as many defects as those who walked in cold. The meeting exists only to combine findings, not to generate them.

The meeting. The reader walks through the code. The tester asks what-if questions. The moderator keeps it under two hours. The author takes notes. Nobody fixes code during the meeting. Defects are logged and the group moves on.

Rework. The author fixes the logged defects alone.

Follow-up. The moderator verifies every defect was addressed. Large reworks may trigger a second inspection.

This structure feels heavy for a modern pull request. Fagan designed it for mainframe software where a single defect could cost millions. The principles still adapt to smaller contexts.

Where This Becomes Overkill

Fagan inspections are not free. The preparation time alone adds significant overhead. For a ten-line bugfix, a full Fagan inspection is absurd. You do not need four people and a checklist to catch a missing import.

The payoff curve is nonlinear. Fagan’s data suggested inspections paid off most for complex, high-risk modules: state machines, parsers, resource managers, anything with non-local state or subtle ordering constraints. For CRUD handlers and boilerplate tests, informal review is fine.

The real mistake is applying the same review strategy to every change. A typo in a log message does not need a Fagan inspection. A distributed transaction coordinator probably does.

A Lightweight Version You Can Use Today

You do not need IBM’s meeting culture to get most of the benefit. Here is a lightweight adaptation that works for modern teams:

  1. Require individual review before group discussion. Every reviewer submits written comments before anyone talks. This prevents the first loud opinion from dominating.

  2. Rotate the reader role. Ask one reviewer to summarize the change in their own words before anyone critiques it. If they cannot, the change is too large or too unclear.

  3. Build a team checklist. Start with the seven questions above. Add domain-specific items. Revisit it quarterly.

  4. Separate author and defender. The author answers factual questions. They do not argue that the code is fine. If a reviewer is confused, that is data, not a debate.

  5. Log defects, fix them later. Do not rewrite code during the review. Log the issue, finish, then fix.

Here is a simple script to generate a review checklist for any Python module:

import ast
import sys
from pathlib import Path

def generate_checklist(source_path: str) -> list[str]:
    """Generate a Fagan-style checklist from a Python module."""
    source = Path(source_path).read_text()
    tree = ast.parse(source)

    checklist = [
        f"Module {Path(source_path).name}: {len(tree.body)} top-level statements",
        "Can a non-author state the module's responsibility in one sentence?",
    ]

    for node in ast.walk(tree):
        if isinstance(node, ast.FunctionDef):
            checklist.append(
                f"Function '{node.name}': does every path return or raise?"
            )
            if any(isinstance(n, ast.Try) for n in ast.walk(node)):
                checklist.append(
                    f"Function '{node.name}': is every exception handled explicitly?"
                )

    return checklist

if __name__ == "__main__":
    for item in generate_checklist(sys.argv[1]):
        print(f"[ ] {item}")

Run it like this:

python inspection_checklist.py src/transaction.py

It will not find your bugs. It forces you to look in the right places.

Hiring Smarter People Will Not Fix a Process Problem

Fagan’s research is nearly fifty years old, but the finding has not changed. Individual reviewers are inconsistent. Groups are inconsistent too, unless you structure them. The variance between reviewers is not a problem to eliminate. It is a resource to organize.

The next time one reviewer catches a bug another missed, do not ask who is better. Ask whether your process is structured enough to combine what both of them see. Fagan already tried hiring his way out of it. It does not work.

FAQ

What is a Fagan inspection?

A Fagan inspection is a formal, structured code review process developed by Michael Fagan at IBM in 1976. It uses defined roles (moderator, reader, tester, author), preparation requirements, and checklists to maximize defect detection in software artifacts.

Why do different reviewers find different bugs?

Human attention is selective. Experts develop mental shortcuts that let them read code quickly, but those same shortcuts create blind spots. Different reviewers have different backgrounds and cognitive patterns, so their blind spots do not overlap perfectly. Fagan’s research showed that the value of inspection comes from combining multiple incomplete perspectives, not from finding one perfect reviewer.

Are Fagan inspections still used today?

The full formal process is rare outside safety-critical industries like aerospace and medical devices. However, the underlying principles, individual preparation, role separation, and checklist-driven review, are increasingly adapted by high-performing software teams. The core ideas also influenced modern practices like structured walkthroughs and formal technical reviews.

When is a full Fagan inspection worth the overhead?

For modules where a defect has severe consequences: distributed consensus logic, security boundaries, resource lifecycles, and state machines. For routine changes, lightweight adaptations are usually enough. Match review rigor to actual risk, not the same process to every diff.