By now, we all know why Code Review is such a critical part of the software development cycle. In fact, we’ve already talked about our view on peer Code Review and its benefits for Agile software development.
Now, we want to propose a better and more effective way to empty those endless “in review” columns in Agile boards faster, by managing and improving your Pull Request workflow.
Git Pull Requests have been used to review code on branches before it reaches master for a very long time. However, this workflow has proved time and time again to be one of the most difficult and time-consuming parts of the software development process.
It often requires experienced team members to spend time reading, thinking, evaluating, and responding to implementations of new features or systems and imposes tracking difficulty on Engineering Managers. It’s no surprise that endless “in review” columns in Agile boards is one of the most common issues raised by software teams during sprint retrospectives.
At this stage in your career, you’re probably done asking “What is a Pull Request?” and are more interested in how to make a better Git Pull Request workflow for your team.
In this article, we’ll tell you how you can make your team’s Pull Request more effective by addressing the 11 challenges you’re facing in your PR workflow and how to overcome them.
We’ll also show you how to use Waydev’s PR workflow analytics features as a solution to the issues this process might pose. Let’s dive in!
Pull Requests (PR) have existed in, essentially, their current form for over a decade. They focus on the changes made to the codebase with information about what change was made to help reviewers and other developers understand and provide feedback.
Before this feature, software engineers and developers used to send patches of code by email. As new tools became available, the process of development modernized itself. Some tools call it Merge Request, or Change Request. In practice, it’s the same thing: an evolution of email threads with patches attached to it.
However, in software development, a PR workflow that’s remained mostly unchanged for over a decade is the equivalent to a lifetime of deficiencies—especially when we take into account the addition of value-add features, such as integrating status checks like CI results, the ability to rebase or squash commits instead of merging, code review tooling improvements, and lots of UI improvements.
We know what you’re thinking: Pull Requests work great and they’re a superior model compared to what came before. That’s 100% true. However, if you’re an Engineering Manager looking to improve productivity and code/product quality, you need to overcome the challenges in the Pull Request workflow and implementation of that workflow in GitHub, GitLab, Bitbucket, or Azure DevOps.
PRs can quickly become one of the biggest sources of pain and frustration in the delivery process. Their biggest drawbacks lie in their detailed nature and time consumption. Like when an engineer opens a PR, and then they wait an enormous time before the reviewer picks it up. This increases Time to Resolve, a metric that looks at the broader picture of how work is being handled during the review process.
Every manager dreams of leading a happy, productive, and high-functioning team. It’s also their job to keep an eye on the produced code and make sure it meets conventions and standards—and PRs help them do just that.
As a consolidated practice, PRs can provide useful and actionable metrics to Engineering Managers. By overseeing their team’s work through Pull Requests, managers can understand technical deficits or spot technical misguidance. They can look at the comments for engagement and lack of specific knowledge. Engineering Managers can also set a basis for a mentoring mindset that uses non-violent language, which can lead to a more harmonious work environment.
Measuring Pull Requests is tricky. Engineering Managers shouldn’t use Pull Request data to assess individual performance, but they can use Pull Requests metrics to understand the team dynamics and act appropriately to correct behaviors before things get out of track. Here are a few suggestions of what to measure.
We’ve looked far and wide and put together a comprehensive list of Pull Request metrics and how to use them. You can calculate them yourselves or take a look at how our Waydev metrics can help you assess Pull Request activity.
Evey Pull Request comes with a set of challenges, which can extend to the individual, team, and technology. Plus, they can happen before, during, or after the creation of a Pull Request.
We know that Engineering Managers are constantly looking for frameworks to build a more efficient Pull Request management system. Here are a few pointers that you can use to move faster in development and deliver priorities on time.
Problem: Having only one team member doing code reviews or code owner increases the likelihood of an error during the merging process, which causes inefficiencies in the team’s workflow.
Solution: Include everyone in the code review process. Engineers can play the role of both submitters and reviewers. To streamline this process, you can try Waydev’s Review Collaboration feature to see code collaboration stats between the submitters and the reviewers and understand how your engineering teams work collaboratively.
Problem: Developers often find themselves involved in a balancing act of trying to maintain their own vision of the project’s future and incorporating (or rejecting) contributions that are tuned to the contributor’s needs.
Solution: Try to maintain discussion etiquette by enforcing politeness rules or stopping long, off-topic, and unhelpful (bikeshedding) discussions from the start.
Problem: Extensive Pull Requests are never good. Developers usually don’t thoroughly review them, which may end up pushing low-quality code forward.
Solution: Have your team make smaller Pull Requests. This is the #1 way to speed up your review time. Because they are so small, it’s easier for the reviewers to understand the context and reason with the logic.
Problem: Sometimes, code is written in a way that makes it difficult to comprehend. If one team member writes code that team members cannot read or recognize, this affects team velocity.
Solution: Establish coding standards and guidelines to help your team ship faster, more often. You can try standardizing the structure and logic of the code so that it’s easier to review and merge.
Problem: When there isn’t enough information on the commits, the reviewer loses context for the code, making the code review less effective.
Solution: Commit message should talk about WHAT changed, and WHY, not necessarily HOW. A high-level summary and understanding of the problem is also very useful for people looking back through a repo’s history, in addition to reading the details of the individual code changes. Putting a Jira issue key in every commit message, so no matter where a user finds a commit message from, means there’ll always be a trail back to the Pull Request. This also helps soften the blow of lower-quality commit messages.
Problem: A lack of a proper description adds a lot of time to the reviewer’s process, because they have to read every file to try and group them up and identify related concepts.
Solution: Make sure that every time someone from your team opens a Pull Request, they fill out relevant and informative information to tell the review team what their contribution is. The most helpful descriptions guide the reviewer through the code as much as possible, highlighting related files and grouping them into concepts or problems that are being solved.
Problem: Developers can experience a volume of incoming contributions that is just too big, which can lead to triaging and work prioritization as challenges. Requests that are kept too long on the project queue, as it moves ahead in terms of functionality or architecture, will be more difficult to merge without conflicts.
Solution: Set a daily limit on Pull Requests. Pull Requests can take between 2 to 3 hours to review. Given most developers work an 8 hour day, that would be about 2 to 3 Pull Requests a day. Next, optimize your review workflow. Identify long-running Pull Requests, unreviewed ones that have been merged, and spot-closed PRs that have not been merged by using Waydev’s Review Workflow feature.
Problem: The distributed nature of pull-based development means that lack of responsiveness on behalf of the contributor hurts the code review process and, by extension, project flow. This lack of centralized coordination can lead to internal chaos.
Solution: Implement a one-to-one task Pull Request, which is an assignment that is allotted to developers. Setting a one-to-one PR standard from the beginning leads to a better workflow, since it helps to create manageable Pull Requests and a consistent system of record. It also gives the team space to focus on details—ensuring that the team is reviewing Pull Requests effectively.
Problem: When two developers have made changes to the same lines of coding or one branch is working on a file that another branch has deleted, Git highlights the conflicting code but doesn’t know which code to keep and which to discard.
Solution: A great way to avoid merge conflicts is through communication. Use Slack for internal communication and short-term updates, such as messaging another developer to make sure the PR looks accurate before sending it off to be merged. You can also use an automated tool that gathers UI feedback to help branches correct any possible merging conflicts before deploying the code.
Solution: Make sure submitters are performing their due diligence before merging. That means reading over the code multiple times, to ensure minimal errors. You can also try to set a team for code reviews: one person who wrote the code and two others to review the code. This minimizes the margin of error, discourages asking for more work from the contributors, and encourages constructive critiquing.
Problem: A typical Github Pull Request workflow implies a lengthy series of reviews and unit tests before the code is officially deployed, to ensure that its functionality is aligned with the repository and any user acceptance criteria.
Solution: Improve speed of PR reviews using these tips:
Everyday, Engineering Managers are faced with a constant battle with ways to improve time spent on Pull Requests and making sure the accuracy behind merging codes stays the same. Here’s how to use Waydev to do just that.
As an Engineering Manager looking to make data-driven decisions and evaluations of your team’s work, you need to:
Waydev’s PR Workflow Analytics bundles up all the features you need to identify bottlenecks, long-running, or unreviewed Pull Requests. That way, you have a better understanding of PRs and improve your engineers’ performance using these four key features:
If you want to gain a better understanding of PRs and improve your engineers’ performance, Waydev is the way to do it right. We provide insightful charts and reports based on your team’s daily activity. A complete picture of Pull Request activity, all in a centralized location.
Start collecting Pull Request Metrics using Waydev to unlock the value of your team’s Git workflow analytics. Schedule a product demo with one of our experts and try Waydev for free.
Ready to improve your SDLC performance?
