I post about code reviews often. For example: how to review pull requests, how to author pull requests, and how to force multiply your code review process.
Often, I get feedback like this:
"We should forget about pull requests, embrace pair programming, and adopt trunk-based development!"
In this post, I'll address this particular piece of feedback. I'll first share some thoughts on pull requests versus trunk-based development. I'll conclude on why the former is critically important, and why I focus on it.
There are two popular development models: the pull request model, and trunk-based development. Software teams may have variations that resemble one or the other, or both. The below sections cover what they generally look like.
The pull request model
The pull request model was popularized by open source.
With the pull request model, code reviews happen asynchronously.
You have one main development branch, often called mainline. A developer creates a feature branch from this branch, and starts making code changes. Once they’ve made and tested their code changes, they create a pull request. Other developers review the pull request (e.g., perform a code review) asynchronously. They either approve it, or comment and request changes. Once approved, the change is merged into the mainline branch.
The pull request model works great in the following scenarios:
- When you have a team distributed across time zones. Given its asynchronous nature, team members don’t need to engage in social programming practices. This gives members the flexibility to contribute code and reviews on their own time.
- When you have an established product. In such cases, time is not a constraint — you rarely need to iterate quickly. You want all code changes to be precise, to reduce risk of breakage.
- When you have junior developers. Pull requests help you to check their work more closely. You can give them specific guidance on how to improve the functionality and readability of their code.
Trunk-based development
Trunk-based development was popularized by the agile movement.
With trunk-based development, code reviews happen synchronously.
All developers work on the mainline branch, committing directly and frequently to it. They generally avoid creating feature branches (but do so occasionally). Developers engage in social programming practices, where multiple developers are present while the code is written. Examples of such practices are pair programming and ensemble working (formerly known as mob programming). Because of the presence of multiple developers, code reviews happen synchronously, and there’s no need for an asynchronous process.
Trunk-based development works great in the following scenarios:
- When you have a co-located team, or a team in the same time zone. This simplifies the scheduling of synchronous, social programming sessions.
- When you have a new product, and need to iterate quickly. In such cases, time is a constraint. You’re in the exploration phase — your customer will change what they want, and you’ll need to quickly pivot to change your product.
- When you have mostly senior developers. You don’t need to watch their work closely, or give them much guidance about their code. You want to give them full autonomy.
Pull requests beat trunk-based development
Trunk-based development is one of the central ideas of continuous delivery. Other core ideas of continuous delivery involve automation techniques around builds, tests and deployments. These ideas are widely adopted across companies like Google, Amazon, Meta, Netflix, Uber and many others.
One idea that’s not widely adopted across these companies? Trunk-based development! The overwhelming majority of software development teams — including most teams at the mentioned companies — use the pull request model.
But, why? Why do so many teams adopt continuous delivery’s principles, while neglecting one of its central ideas?
It’s difficult to say. This insightful article — How open source beat agile — by Lorin Hochstein makes a compelling speculation:
"In open source, the entire process is visible, by definition. We can observe how projects do code reviews, integration tests, new feature planning, and so on. In the world where agile came from, we can’t. We have access to books and talks by consultants, but we don’t get to see how they applied their skills to solve specific difficulties they encountered with agile… Because open source succeeds in making work visible where agile fails, developers have more opportunities to become better open source developers than agile developers."
In short: open source development was mostly executed in a transparent nature, giving visibility to the public. Agile and trunk-based development, while publicly documented, were mostly executed through the work of private consultants. The extra transparency gave open source development an advantage in influencing modern software development, which is probably why the pull request model is so dominant today.
What about pair programming?
Pair programming is a great tool. Done well, it can result in better mentoring, knowledge sharing and team morale. It's especially effective within the trunk-based development model, but it can also be used within the pull request model.
Depending on the situation, a team may decide to use pair programming, asynchronous code reviews, or both. Usage of one tool doesn't force the complete elimination of another.
What about the term, code reviews?
Earlier, I mentioned that I post about code reviews often. But this is frequently a point of contention, and there's opportunity to clarify here.
As described, code reviews happen in both the pull request model and trunk-based development. But because the pull request model is so dominant, most developers more readily recognize code review in the context of that model — e.g., asynchronous reviews. So, my posts generally assume that the reader is operating within that model.
I use the term code reviews because pull requests would lead to too much confusion: the tips I give are agnostic to a GitHub context. They aren't specifically for open source developers. Rather, they're meant for developers operating within a team, contributing to a product for a company.
The various nomenclature is actually a humorous head-scratcher on my end, making my content a lot more difficult to write:
Operating within the pull request model is a critical skill — I'm here to help
The topic of pull requests versus trunk-based development is a common debate across the industry. Many influential developers have weighed in, arguing each side.
My intention here isn’t to tell you to favor one or the other. Each organization should choose the style that works for them.
However, a few things are clear: the pull request model is dominant — for the reasons above, or otherwise. It works for many companies. In many cases, it's embedded within the company culture. It's not going away any time soon.
Thousands of developers participate in the pull request model, and will continue to do so. And those developers need help — because succeeding within that model is a critical skill.
In 2021 Dropbox publicly published their Engineering Career Framework. The document details the expected key behaviors for a variety of roles, like software engineers. Many big companies have similar internal guidelines.
Included in Dropbox's:
"I ensure high code quality in code reviews."
"I... set and hold the bar for quality and best practices for my team (e.g. via code and design reviews)"
"I solicit and offer honest and constructive feedback that is delivered with empathy to help others learn and grow."
There's no denying it — succeeding in code reviews is critical for software engineers who want to level up.
With all this in mind, let's revisit the piece of feedback from the beginning of this article.
When I post about code reviews, I often get feedback like this:
"We should forget about pull requests, embrace pair programming, and adopt trunk-based development!"
I can see how this piece of feedback is a useful argument for those who wish to influence an organization towards the trunk-based development model. But as mentioned, that's not my position — my position is to give guidance to developers already participating in the pull request model.
In that context, this feedback becomes counterproductive. We can't simply tell all developers to forget pull requests, and switch to trunk-based development.
That advice doesn't work for the junior software engineer at Amazon, who's just received 20 comments on a PR, and doesn't know how to defend themself.
That advice doesn't work for the mid-level software engineer at Microsoft, who's staring at a PR, and doesn't know how to give constructive feedback.
That advice doesn't work for a senior software engineer at Uber, who finds themself a bottleneck in their team's code review process.
So I'll keep writing about code reviews, and hopefully it's helpful. 🔹
Like this article?
Turns out, code reviews are my thing. Check out my video course, Master the Code Review! Individual and team licenses available.
