In modern software engineering, few practices are as widely accepted and as rarely questioned as code review. It has become a pillar of collaborative software engineering and, for many teams, a non-negotiable step in shipping anything at all.
But what if we stopped?
I mean this literally: what if we put code review on pause for some time (say, four weeks) and systematically study what actually happens? Not as an act of rebellion or chaos engineering, but as a research experiment to illuminate what we truly gain and what we mistakenly assume we gain from one of the most time-consuming collaboration rituals in software development.
As a software engineering researcher who has dedicated much of his work to understanding code review, I believe there is real value in proposing exactly this. Let me explain.
Why Studying Code Review by Taking It Away#
Every ubiquitous software engineering practice carries legacy assumptions. Some validated, some unexamined. Code review is no exception. Most teams would struggle to articulate precisely which benefits they rely on most. Is it defect detection? Architectural alignment? Mentoring? Social cohesion? Organizational memory?
By intentionally removing the practice in a controlled context, we gain an opportunity to observe:
- Which defects actually reach production?
- Which collaboration patterns break down?
- Which communication channels emerge naturally?
- How developer autonomy and confidence shift without gatekeeping?
- How bottlenecks, lead time, and throughput behave when reviews are gone?
- Understanding what code review truly guards against is often easier when those guards are removed.
What We Might Learn#
This stoppage could reveal insights that rarely surface in software engineering research otherwise:
- The Invisible Work of Code Review: We may confirm our theory that its primary value isn’t defect detection at all, but the subtle alignment and socio-technical cohesion it creates: code review as a communication network.
- The Real Cost of Waiting: Without reviews, lead time might drop dramatically—shedding light on the hidden tax of asynchronous approvals.
- Natural Substitutes: Developers might immediately replace reviews with pairing or lightweight design discussions, suggesting that some teams perform review only because the workflow mandates it, not because it’s the optimal method.
- Role of Psychological Safety: Some developers may feel liberated; others may feel exposed. This tension is a rich source of insight into how review systems shape team culture.
Call For Participation#
Experiments are inherently difficult in software engineering because real projects involve complex, ever-changing combinations of people, processes, and technologies. It’s hard to isolate variables, control conditions, or prevent developers from adapting their behavior during the study. As a result, even simple interventions become challenging to evaluate rigorously in real-world environments.
If your team or company is brave enough for such a step: Please reach out!
