Code Smells Are a Symptom: Fix the Process, Not Just the Code

Here's a number that should haunt you: at Google, more than 80% of code reviews finish in a single iteration of resolving comments (Modern Code Review: A Case Study at Google). That's not because Google hires only geniuses. It's because their review process is engineered for speed and small, reviewable changes. Most teams chase code smells with static analysis tools, but the data says the real cure is in the process, not the linter.

The Smell Is in the Process, Not the Code

Code smells—those ugly patterns like god objects, long parameter lists, and duplicated logic—are symptoms. The disease is a review process that encourages bloated, unreviewable PRs. Google's own guidance says a 100-line change is reasonable, 1000 lines is too large, and a 200-line change across 50 files is probably too big (Google Engineering Practices - Small CLs). Yet most teams let PRs balloon to thousands of lines, then wonder why reviews drag on and smells sneak through.

When a PR is huge, reviewers can't focus. They skim, they miss the logic errors, and they default to nitpicking style—which is exactly what automation should handle. The result: smells survive, and the codebase rots. The fix is to make changes small and reviewable, not to add more rules to your linter.

Speed Is a Feature, Not a Luxury

Google sets one business day as the maximum time to respond to a review request (Google Engineering Practices - Speed of Code Reviews). Their median time to first feedback for small changes is under one hour, and the overall median review latency is under four hours (Modern Code Review: A Case Study at Google). Compare that to Microsoft, where median approval time runs 14.7 to 24 hours. Slow reviews kill team velocity and, more insidiously, they make developers resent the process. When reviews are slow, developers game the system: they bundle changes to minimize review count, and they push back on legitimate feedback just to get the merge through.

Speed doesn't mean sloppy. Google's “LGTM with comments” technique lets reviewers approve while leaving minor, non-blocking comments, so the process doesn't stall over trivia (Google Engineering Practices - Speed of Code Reviews). The key is distinguishing between what must be fixed and what can be deferred. That's a judgment call, not a rule—but it keeps momentum.

Static Analysis Is a Tool, Not a Crutch

Don't get me wrong: static analysis has its place. SonarQube's metrics—cyclomatic complexity, cognitive complexity, duplication, technical debt ratio—are useful signals (SonarQube Server Docs - Understanding measures and metrics). But here's the catch: a tool can flag a smell, but it can't tell you whether the smell is worth fixing now or whether the design is wrong in a way that metrics can't capture.

Google's own research found that finding bugs is not the primary focus of code review—education, maintaining norms, gatekeeping, and accident prevention matter more (Modern Code Review: A Case Study at Google). Static analysis can catch injection flaws and security vulnerabilities (Semgrep, Bandit, gosec all do this well), but it can't teach your junior dev why over-engineering is bad. That's a human conversation, and it only happens in a review that's small enough to have that conversation.

The Counterargument: But We Need to Catch Everything

You might say: “If we make reviews fast, we'll miss bugs. We need thorough review.” That's the classic speed-versus-quality tradeoff, and it's a false dichotomy. DORA's research has repeatedly shown that speed and stability are not a tradeoff—top performers do well on both (DORA). The secret is that fast reviews are possible only when changes are small and the process is disciplined.

Consider the numbers: at Google, the median change size is about 24 lines, and more than 35% of changes touch only one file (Modern Code Review: A Case Study at Google). A 24-line change is easy to review thoroughly. A 1000-line change is impossible to review well, no matter how much time you throw at it. Small changes are also easier to roll back if something goes wrong (Google Engineering Practices - Small CLs). So the counterargument collapses: thoroughness isn't about time, it's about size.

What to Do Instead of Chasing Smells

Here's my recommendation, and it's not sexy: stop trying to eliminate every code smell. Instead, fix your review process.

• Keep PRs under 400–500 lines of meaningful change (Google Engineering Practices - code review).
• Respond to review requests within one business day (Google Engineering Practices - Speed of Code Reviews).
• Use 'LGTM with comments' for minor issues—don't block the merge over style.

Let automation handle style and security scanning. Save human review for design, logic, and edge cases. When you do that, code smells become a signal that the design is off, not a checklist item. And you'll have the time to have the conversations that actually improve code health.

The One Thing to Remember

The next time you see a code smell, don't ask “How do I refactor this?” Ask “Why did this change get so big that the smell slipped through?” Fix the process, and the smells will take care of themselves.

Sources

• Google Engineering Practices - Small CLs - https://google.github.io/eng-practices/review/developer/small-cls.html
• Google Engineering Practices - Speed of Code Reviews - https://google.github.io/eng-practices/review/reviewer/speed.html
• 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
• DORA - Software delivery performance metrics - https://dora.dev/guides/dora-metrics-four-keys/