Smaller Pull Requests are like Faster Horses

Michael GershMichael Gersh
April 30, 2021

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. 

PR-Driven Code Reviews Reimagined Code Reviews
The author needs to commit and push in order to request a review. The word “commit” itself is a deterrent to wanting to ask for some quick, perhaps informal, feedback. One may want some feedback on some code before, well, committing to it. Authors should be able to request a code review on any line of code at any time regardless of status. Committed or uncommitted. Just work-in-progress. The mental effort of internally debating whether code is commit-and-push worthy should not be part of the thought process of getting a review. Want help? Second set of eyes? Just ask.
Depending on which code host and IDE you use, committing, pushing and creating a PR either require multiple extensions or, more likely, a visit to the web. Authors should be able to request feedback from their IDE. Leaving the IDE for any reason is a context-switch and context-switching means breaking-flow and would inhibit requesting a code review.
Reviewers are often looking at the code to be reviewed outside the context of the full-file or codebase. Most web-based code review tools only offer the reviewer the diffs and a few lines before and after.The result is often a superficial “LGTM” focused on things like syntax and variable naming conventions. Reviewers should be able to view diffs in a file-file context in their IDEs. Both for the benefit of more meaningful and useful full codebase context, but also for avoiding the risk of distraction associated with leaving the IDE.
For a reviewer to look at changes in their IDE with full-file access they may need to switch branches or stash their work. This is indeed the interruptive distraction referred to above.  Reviewers should be able to review code in their IDEs, with full-file context, and the context of the author’s branch without any need to pull, switch branches or stash. Likewise they should be able to seamlessly return to their work.
Due to all the friction involved in reviewing, authors are often inhibited from requesting reviews for fear of interrupting and distracting others. I, for one, would be less likely to ask a teammate to go through that effort for feedback on a single line of code.  Making code reviews easier for the reviewer reduces the interruption and distraction factor that prevents an author from asking for iterative feedback.


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.

Discuss

Please share your thoughts and feedback @teamcodestream.

About CodeStream

CodeStream integrates all of your essential dev tools, such as GitHub, GitLab, Bitbucket, Slack, Teams, Jira, Trello and more, into VS Code, Visual Studio, and any JetBrains IDE.

Thank you for your interest in CodeStream.

We'll be in touch shortly.
Oops! Something went wrong while submitting the form.
CodeStream Demo Time

During our daily stand-ups we demo features in development to allow everyone, which now includes you too, to stay in the loop and provide early feedback.

Recent Blog Posts

Two Ways to See for Yourself