Maybe We Shouldn't Be Reviewing All This Code

I am Rachel Laycock, CTO at Thoughtworks. I am endlessly curious about how technology is changing the way we build software, lead teams and run businesses. Recently, I participated in a panel discussion with Brian Houck from DX at Code Remix, hosted by Moderne. Although we disagreed on certain points, we both had strong arguments.

Brian has written a piece called "What are code reviews even for?" expressing his concerns about the current state of code review. He cites statistics showing that at Meta, lines of code per human-landed diff increased by 106% in a year, and the median pull request size grew by 64%. He worries that automating code review away might cause us to lose valuable aspects of the process, such as knowledge sharing, teaching junior engineers, building collective ownership, and spreading architectural understanding.

While I agree that code review is not solely about bug detection, I believe we should rethink the role of code review in our software development process. I have always been skeptical of pull requests being the center of the software development process. I prefer to build, finish, and discuss our work together rather than separating the work and having a conversation about it later.

Pair programming, trunk-based development, automated testing, static analysis, fitness functions, and security scanning are all methods that move feedback earlier and help the whole team benefit from experienced human input.

While it is true that some changes require human judgment, we should not require humans to inspect every single change. Instead, we should focus on the cases where human expertise is truly valuable, such as fundamental architectural changes, sensitive security boundaries, huge blast radius changes, unfamiliar critical system parts, or when the team lacks confidence in a particular change.

By doing so, we can avoid creating a backlog of changes waiting for senior engineers to review and prevent a new bottleneck from forming.

Brian raises a valid concern about accumulating cognitive and intent debt in software as it grows. However, I believe that mandatory pull requests are not the strongest defense against this issue. Instead, I suggest a collaborative approach, where the team works together during the design process and acts like a single entity throughout the development process. This way, we can ensure that experienced human knowledge benefits the entire team and helps mitigate the risk of accumulating technical debt.