Formal vs. Informal Code Review: Which Team Process Wins?

What's the best code review process for my team?

That's the question I get more than any other from engineering leaders. They've heard of formal inspections, they've read about Google's lightweight approach, and they're torn. Should we schedule review meetings? Should we rely on pull request comments? In my years editing this publication, I've seen teams crippled by both extremes. Let's cut through the noise and compare the two main contenders: the formal, staged inspection from the 1970s and the modern, asynchronous, tool-based review that powers Google and most of the industry today.

The contenders: Fagan inspection vs. the modern review

On one side, we have the Fagan inspection—a heavyweight process with defined stages: planning, overview, preparation, inspection meeting, rework, and follow-up, all overseen by a moderator. It was developed in the 1970s and is the archetype of formal review. On the other side, we have the modern review: informal, tool-based, and asynchronous, where developers submit changes and reviewers comment online. This is what you get with GitHub pull requests, GitLab merge requests, or Gerrit. The academic literature calls it 'modern code review,' and it's the default for a reason.

Criterion 1: Speed of feedback

Speed is where the modern approach crushes the old guard. Google, the poster child for modern review, sets a one-business-day maximum for a response to a review request. Their internal data shows a median time to first feedback of under one hour for small changes, and an overall median review latency of under four hours—far faster than the 14.7 to 24 hours seen in Microsoft projects. In contrast, a Fagan inspection requires scheduling a meeting, which means waiting for everyone's calendars to align. That alone can eat a week. When you're shipping code, a day of delay is a lifetime. The modern review wins this criterion hands down.

Criterion 2: Thoroughness and quality

You might think formal inspections catch more bugs because they're so deliberate. But the data says otherwise. At Google, the four key expectations of code review are education, maintaining norms, gatekeeping, and accident prevention—finding bugs is not the primary focus. In other words, the process is about keeping the codebase healthy, not perfect. And it works: their median change size is about 24 lines, with over 10% of changes touching a single line. That's the opposite of a giant 1,000-line review, which Google explicitly says is too large. Small, focused changes are reviewed more thoroughly and are less likely to introduce bugs. A formal inspection, with its meeting and moderator, is too slow to keep up with that pace. It's like using a sledgehammer to crack a nut.

Criterion 3: Flexibility and automation

Modern review tools are incredibly flexible. You can automate the boring stuff—linters, formatters, static analysis, secret scanners, and dependency scanners—so human reviewers can focus on logic and architecture. Tools like SonarQube can enforce a quality gate, blocking a merge if new code doesn't meet coverage thresholds. GitHub lets you require approvals from code owners and protected branches, and even dismiss stale approvals. GitLab goes further with required approvals and category-based reviewers. Fagan inspections, by contrast, are manual from start to finish. There's no integration with your CI, no automated checklist. It's rigid and doesn't scale.

Criterion 4: Team satisfaction and culture

Finally, consider the human factor. Google's internal review tool, Critique, has a 97% developer satisfaction rate. That's remarkable. The modern approach respects developers' time and autonomy. You can approve with 'LGTM with comments' when you're confident the author will address minor suggestions—like sorting imports or fixing a typo. This keeps the process moving and reduces friction. Formal inspections, with their mandatory meetings and moderator, can feel like a courtroom. They're stressful and can breed resentment. The golden rule of code review is to critique the code, not the author. That's much easier to do when you're writing a comment than when you're sitting in a room with the author, staring at a projector.

Who each option is for

So, who should use Fagan? Honestly, almost nobody. It might make sense for a safety-critical system where every line must be scrutinized, like aerospace or medical devices. But even then, modern tools can provide the same rigor with less pain. The modern review is for everyone else—from a two-person startup to a 25,000-developer Google. It's especially suited for distributed teams, because it's asynchronous. You don't need everyone to be online at the same time.

What I'd actually do

Here's my concrete recommendation: if you're starting a new review process or revamping an old one, go modern. Use a tool like GitHub or GitLab. Keep your pull requests small—under 400-500 lines of meaningful change, and ideally closer to the 100-line mark that Google suggests. Require one or two approving reviews before merge, and use branch protection to enforce it. Set a team norm that review responses come within one business day. And remember, the primary purpose of review is to improve overall code health, not to find every bug. As Google says, there is no such thing as perfect code, only better code.

Quick tip: If you're a reviewer, try the 'LGTM with comments' trick—approve the change while leaving minor comments, and trust the author to address them. It keeps the pipeline moving.

Sources

• Google Engineering Practices (code review) - https://google.github.io/eng-practices/review/
• Modern Code Review: A Case Study at Google (ICSE-SEIP '18) - https://www.papercache.org/papers/mlsys/system/2026/03/25/modern-code-review-a-case-study-at-google
• GitHub Docs - About protected branches - https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
• GitLab Docs - Merge request approvals - https://docs.gitlab.com/user/project/merge_requests/approvals/
• SonarQube Server Docs - Understanding quality gates - https://docs.sonarsource.com/sonarqube-server/2026.1/quality-standards-administration/managing-quality-gates/introduction-to-quality-gates