Why you should measure your pull requests?
Pull requests help developers notify their peers that they have finished a particular piece of work, it could be a feature or a fix. This gives a chance to share your work and get feedback. It builds a context for the whole team that helps them understand what the other one is working on. I have seen some engineering teams that are very rigid with their code review processes and are very skeptical about it. They don’t want to push something to production which is not reviewed or understood correctly.
A typical software delivery pipeline would include the following steps :
- Requirement analysis
- Design
- Development
- Testing
- Deployment
However, I have noticed that code review is also an important step in the process and is often included after development is complete or testing is on going.
Having said that, if code review’s are delayed, your release cycles would also get delayed. Often, engineering managers are in a dilemma. They are not too sure what is clogging their code review cycles. It could be that your pull requests are way too long to be reviewed in a short span of time, or may be there are long open discussions, or may be your team is not quite serious about open pull requests. Reasons could be many, but this explains that your team is not in sync.
The point that needs to be understood is that code reviews require a collective effort, it’s not one person’s job. The whole team needs to be in sync in order to make sure that your review cycles are functioning smoothly. Now in order to understand what is exactly clogging your review cycles, you need to dig a little deeper and understand your team’s dynamics. Basically, you need to start driving insights and measure your pull request metrics.
What are Pull Request Metrics?
Well, metrics in general are numbers that tell you important information about a process under question. They tell you accurate measurements about how the process is functioning and provides a base for you to suggest improvements. With the same analogy, Pull Request Metrics help you to understand your software engineering teams dynamics. Using a couple of metrics together you can measure the effectiveness of the process. Have your releases been delayed because of long lying open pull requests? Why do you think your team is not able to squash those pull requests in time? Why are those pull requests not able to seek attention of your team? Why ….? Why and Why?
Let’s take a look at a few pull request metrics:
- Lead Time : Tells you on an average how many days pull requests take to be merged or closed.
- Time to Merge : Tells you how many days it takes for the first commit of a branch to reach master.
- Size : Depending on the number of lines of code changes, it requires more or less effort to review. Usually, developers tend to merge long pull requests faster. People feel lazy to perform thorough reviews when there are too many things going on. So, they immediately approve changes.
- Discussion : By discussion, we mean the number of comments and reactions per pull request. Unlike social media posts, too much engagement in pull requests leads to inefficiency. Measuring the number of comments and reactions for each pull request gives you an idea of how your team collaborates.
- Flow Ratio : It is the ratio of sum of pull requests opened in a day with respect to the sum of pull requests closed in that same day. This metric tells you whether your team works in a healthy proportion.
Using the above metrics collectively you could spot trends and behaviors effectively.
This would initiate the process of measuring your pull requests. Access to such metrics would help you to understand where exactly the problem lies so that you can take actionable steps.
CodeKickBot is a GitHub and Slack integration that helps you to drive insights from your pull requests right within your Slack workspace. It makes collaboration on pull requests easy and fun!