What distinguishes an informal read, a walkthrough, a technical review and a formal inspection?

## A spectrum, not four unrelated things Review practices differ along two axes: how much structure surrounds the reading, and what the reading is *for*. Naming the points on that spectrum matters in interviews because teams use the words loosely — "review" gets applied to everything from a two-line remark to a chartered meeting with recorded outcomes — and a candidate who can separate them can also argue about which one a given piece of work deserves. ### Informal read One peer reads the change and responds. No roles, no agenda, no record beyond the comments themselves, no defined completion condition other than the reviewer saying they are content. This is what most day-to-day review is, and its strength is exactly its cheapness: the cost is low enough to apply to every change, which is what makes it the only practice with full coverage. Its weaknesses follow from the same property — nothing forces preparation, nothing records what was and was not examined, and its thoroughness varies with whoever happens to be reading. ### Walkthrough A walkthrough is **author-led**. The author takes an audience through the work product, explaining it as they go, and the audience asks questions and raises concerns. Because the author drives, the primary product is *shared understanding*: the audience learns the design, and the author is often forced to notice problems simply by having to narrate their own reasoning aloud. It is the natural choice for onboarding people onto unfamiliar code, for socialising a design before anyone commits to it, and for work only one person currently understands. The structural weakness is also the author-led format: the audience sees the work through the author's narration, in the author's order, with the author's emphasis, so it is a weak instrument for finding what the author never considered. ### Technical review A technical review is a peer evaluation of whether a work product conforms to its specification, its standards, or the plan it belongs to. Participants are chosen for relevant technical qualification, it is normally led by someone other than the author, and it produces a judgement — the work product is acceptable, acceptable with changes, or not acceptable — rather than merely a set of observations. Its purpose sits between the walkthrough's understanding and the inspection's defect hunt: it asks "does this meet what we said it must meet?" ### Formal inspection The formal end of the spectrum defines *roles*, *stages* and *criteria*. The classic roles are a **moderator** who plans the inspection and keeps the meeting to its purpose, the **author**, one or more **inspectors** or reviewers, a **reader** who paraphrases the material aloud so the group examines a neutral rendering rather than the author's narration, and a **recorder** or **scribe** who logs every defect raised with its location. The classic stages, from the classic formal inspection method Michael Fagan described, run planning, an optional overview, mandatory individual preparation, the inspection meeting itself, rework by the author, and follow-up to confirm the rework happened. Two rules do most of the work. **Entry and exit criteria** state what must be true before material may be inspected (it compiles, it passes its automated checks, the author has self-reviewed) and what must be true before the inspection is complete (every logged defect is dispositioned). And the meeting **finds defects rather than fixes them**: as soon as the group starts designing a fix, the remaining material stops being examined, so fixes are the author's rework, not the meeting's output. ## Choosing a point on the spectrum The honest answer to "which should we use" is: match the cost to the cost of an escape. Formal inspection is expensive per line of material — preparation time multiplied by participants — so the sensible targets are narrow: a contract many teams will depend on, an algorithm that is hard to test, a security- or safety-relevant path, a migration that cannot be run twice, or work under a regulatory obligation that requires records. Everything else gets the informal read, which owes its value to being applied everywhere. Walkthroughs earn their place where understanding, not defect count, is the scarce thing. One caution worth voicing in an interview: the striking defect-removal figures reported for formal inspection come from a small body of older studies, in development contexts with slow build feedback, weak automated checking and long release cycles. The technique is real and the roles are worth knowing, but extrapolating those numbers to a team with fast automated verification is contested, and a candidate who quotes a percentage as settled fact is overreaching. What survives the transfer is the mechanics: preparation before the meeting, a neutral reading, logging instead of fixing, and explicit criteria for being done.