We have known for some time that smaller code reviews earlier in the development process increase code quality. It’s a topic we’ve covered at length previously and there are numerous white papers and research articles on the topic, such as Michaela Greiler’s Code Reviews at Google are lightweight and fast. 

Some people still disagree in spite of the evidence. Some of the arguments we have seen against smaller, earlier code reviews tend to conflate code reviews with pull requests. “Smaller code reviews don’t work because…” is often followed by flaws, issues or limitations of doing code reviews as part of a pull request, which then leads to a debate about whether or not a development team should do more pull requests or not. So many teams equate a code review with a pull request that the notion of decoupling these two activities seems foreign to some developers. 

Smaller, more frequent pull requests are often suggested as a solution for how to do smaller more frequent code reviews. For example,  Why small merge requests are key to a great review suggests that “The only thing worse than writing a long merge request is reviewing a long merge request.” where “reviewing” is literally tied to the request. You’ll also find plenty of discussion on the twitterverse along the lines of

We wholeheartedly over the top agree that everyone should “review early and often” and “small [reviews] improve quality and avoid rework”, but not with necessarily equating code reviews with pull requests. Solving for more frequent reviews by suggesting smaller pull requests (or merge requests) reminds me of a famous quote (likely inaccurately) attributed to Henry Ford:

“If I had asked people what they wanted, they would have said faster horses.”

Both faster horses and small pull requests are solutions to a problem that look at the status quo and all of the inherent limitations of that status quo, and adjust the single, most obvious,  variable – speed or size – in order to accomplish the desired outcome. 

How do I shave a few minutes off of my horse-and-carriage trip to the market? Faster horse.

How do I do a smaller PR-driven code review? Smaller PR.

To come up with a viable forward-thinking solution you need to look at, and try to address all of the limitations of the current process, not just try to tweak only one of them.  Let’s take a quick look at some of the limitations of a pull-request code review and what a reimagined solution to earlier, smaller code reviews would look like. 

With CodeStream’s Feedback Requests (“FRs”) we reimagined the code review. We considered the current state of the art - most developers today use one or more modern extensible IDEs and git based code hosts are now the norm. In that context FRs represent a big leap forward.

By no means though are we eschewing the use of pull requests nor the use of them for any kind of code review. FRs work well with pull requests. For example, when generating a pull request from CodeStream, information about the FR (reviewer, date, permalink to the FR) is included in the PR’s description for audit purposes. We just believe that, in most cases, pull requests are best suited for a final stamp of approval and not for iterative, continuous, smaller and earlier reviews, and that’s not a new concept.

Until now though, most discussion around an alternative form of code review that’s conducive to smaller and earlier review has been just that, conceptual. Feedback Requests make it a reality.