Agile Pull Requests and Code Reviews?
Pull requests can slow you down, but the issue is often less the PR process than the environment and expectations around the process.
When talking about team software development, many will agree that the following are both true:
Small changes, integrated quickly, are good.
Feedback from others helps improve the code.
These seem to be at odds with each other: feedback slows down integration, and given the overhead for feedback, smaller reviews are most costly. In particular, when teams use Pull Requests for feedback, dysfunctional patterns can emerge, making it hard to integrate code quickly. But there are ways to achieve a balance between getting feedback, stability, and speed using Pull Requests if you consider :
What’s the smallest change that makes sense to integrate?
How frequently do you want to integrate?
What kind of feedback should you expect from team members?
What’s the likelihood (and cost) of an error slipping through?
The answers will vary from team to team. As you work to discover the best answers to these questions, you can improve your process by taking incremental steps towards faster, more frequent integration by using a Main Line Model, which provides a path to balance stability and speed. Your goal isn’t to use a particular branching model, but rather to ensure that code is integrated quickly and reliably. There are many ways to achieve this.
Main Line Frequent Integration
When Brad Appleton and I wrote Software Configuration Management Patterns, we emphasized Main Line development. The main principle of Main Line development is to integrate work quickly into a single code line. If you use branches, they are short-lived, and if you don’t use branches, your work is isolated in your workspace only for a short time. This is similar to Trunk Based Development (which does allow for short-lived branches) and also to what Fosgren and Humble reported in the book Accelerate. The SCM Pattern Language (and in the book, and as being revised) describes the patterns related to testing, Continuous Integration, and team commitment to providing prompt feedback that make Main Line Development work well.
Regardless of the branching model you choose, focus on ensuring that work is integrated at the desired frequency and without critical errors.
The Case for Code Reviews
While data is mixed, some believe that code reviews are good things. Code reviews can help to identify misunderstandings in intent, clarify newly discovered best practices, or serve as a check that someone else can understand and maintain your code. Code Review can happen in many ways, though Pull Requests are a common and often maligned format.
Using Pull Requests for code reviews can delay integration (as can non-prompt code reviews via other mechanisms). The presence of a code review or a branch isn’t the core problem in these situations. Changing to a model like Pair Programming and working without branches can address some of the issues of other code review mechanisms, but it’s hard to do Pair Programming effectively and consistently, and Pull Requests offer some affordances.
You can use a Pull Request and achieve frequent integration if you attend to fixing bottlenecks.
The Useful Pull Requests
When I’m talking about Pull Requests, I’m not talking about the problematic high latency, low context, necessarily asynchronous Pull Request approach some teams use. Pull Request reviews can be prompt, high context, and even synchronous. Getting feedback need not be a high-friction event in your development process. Pull Requests can facilitate :
Automated checks that can catch more mechanical errors, ensuring that team members can focus on the places where they add the most value.
Collaboration with remote team members, synchronously or asynchronously.
Measuring how long it takes for code to integrate, so that you can find bottlenecks in your process.
In short, pull requests can improve feedback and quality. If your team is meeting its goal for how quickly changes get merged into the Main Line (and working to increase the frequency), any process can work for you.
Agile Pull Requests?
The goal of any project is to integrate code that you are confident in with a reasonable frequency. Branches and pull requests can be part of your process as long as you meet the goal of integrating frequently enough. If you do the following steps you can have agile pull requests.
Agree on what a reasonable commit rhythm is for your team. Once a day can be typical
Establish guidelines for latency for reviewing Pull Requests.
Gather metrics to help you understand how long Pull Requests are open.
When PRs appear to be a bottleneck, seek to understand why.
If you: work in small units and establish mechanisms to make peer review more effective and quick, your review process need not slow you down. It’s worth experimenting with other approaches, especially if you are in a small, highly cohesive team. But for most teams that already have a Pull Request model, you can get a lot of value by thinking about how to make your Pull Requests better.
I’ll have more to say about intent and context in the context of Pull Requests shortly.