Integrating Code Quickly
Integrating Code Quickly
A systems thinking approach of better reviews, including Pull Requests
There are a couple of things many developers agree about:
Integrating code quickly is generally better.
Getting Feedback on changes before you integrate them is usually valuable
There is often debate around:
What “quickly” means and how to balance “quick” with “complete.”
How to get feedback on code
Pull Requests are a common mechanism for getting feedback, and they can be done poorly, but the flaws people see aren’t inherent in the mechanism. There have been some insightful conversations on Linked In on the role of Pull Request Processes (and branching) in the delay. A recurring theme is that the answer is to get rid of PR mechanisms (and perhaps branches). I think experimentation with new approaches is valuable, but process change without the goal in mind can lead to worse outcomes — consider all the stories of “the problem with Scrum,” which end up being stories of teams following mechanisms without any focus on the principles of feedback and change.
As a team, you want quick integration into the Main Line with a small chance of introducing an error.
Skipping your current PR process alone might speed integration but could add errors. And the prerequisites for a better PR process are the same as those for a “No PR” process.
Utility of Pull Requests
Pull requests offer some advantages as a feedback mechanism :
Tools can identify many potential issues, and PRs provide a convenient place to run static analysis and related tools, showing the results in context and allowing humans to focus on more contextual concerns
In Regulated Environments, you may need to document reviews; PRs are a natural place for this.
If you work in a remote environment, a Pull Request provides a convenient platform for people to read and comment on code, which still allows collaborative real-time feedback sessions
PRs provide a platform for reading and learning from the code and the feedback.
Should an error occur after a merge, a PR provides some context for identifying improvement (not blame!) in a retrospective
Because you use PRs already, and incremental change is often easier.
While I generally don’t like a “because this is how we do it” answer to “why?” questions, in cases where you can propose changes that can improve a process, advocating for incremental change is often the more effective approach to start.
Some of the items on the list above can be done in other ways, but they are often trivial in most PR tools. While a PR does enable asynchronous feedback (which isn’t inherently bad), and delays in feedback loops (which usually is bad), you candefine a process that works more quickly.
When Feedback Goes Bad
There are some common themes around poor code integration processes:
Code that is completed is slow to get feedback
Feedback is missing context
The change is large, leading to complex feedback
Whether you use a Pull Request or not, these items are issues, and the fixes are outside of the PR (or other feedback) mechanism.
Good Reviews
The things that you can do to fix a bad feedback process often involve change outside of the PR mechanism. Some of these things might be outside the direct power of the team, but the team can still influence and support their implementation:
Committing smaller units of work to allow for more focused feedback. The team can plan to split work into Small Development Tasks
Acknowledging that collaborating on code review is part of the development process and prioritizing it. The team needs to know that the delivery of features as a Team is the goal, not individual work assignments. If this doesn’t happen, there are metrics you can gather to demonstrate the impact of lack of prioritization.
Ensuring that someone on the team is familiar with the tasks being committed Always have two people in design and requirements discussions. The Development Partner can be part of a programming pair or someone working on a related task — the important thing is that the work isn’t done in a silo. On an agile team, work assignments should be self-selecting, but the team can still choose to collaborate on some level if there isn’t a lot of micromanagement.
These items are necessary for rapid integration, whether you use a Pull Request process or reviews in a development workspace. Getting these process changes might be challenging if your culture isn’t amenable to incremental improvement, but probably not harder than abolishing a PR process.
Faster integration is about more than pull requests. I’m compiling a Pattern Language, which builds on Software Configuration Management Patterns, that captures many of the elements for faster integration in context. To understand why your Pull Requests are too slow, you can capture metrics about:
Time for people to start reviews
Complexity of the code being reviewed
Cycle time to discuss feedback
These are some common challenges, but not an exhaustive list.
Even if you don’t start with hard metrics, you can get a sense of the issues by asking about impressions (which you can then support with metrics).
While some of these changes —especially those around priorities and task allocation — might need buy-in from project and product management, the team can still do a lot by:
Making the impediments visible by gathering data. This will help motivate changes to the process.
Planning on doing smaller engineering tasks and on having at least 2 people involved in the design and review of non-trivial work. This can address delays due to complexity and context.
Committing to each other to be more responsive about supporting team members whose work needs feedback. This can address cycle time.
Adding automation to the PR and Build pipeline to catch known errors. This will increase the quality of feedback and responsiveness.
If, at the end of all this, everything is working so well that the PR Process Itself is overhead, consider alternatives. By focusing on the goals, you can find a good solution to slow code integration. given your organizational constraints