Size does matter!

Merge requests are an essential part of modern software development. They allow teams to collaborate on complex projects and make changes to codebases quickly and efficiently.

However, determining the optimal size of a merge request can be a challenging task. Too small, and the code may lack context, making it difficult to understand and review. Too large, and the changes can become overwhelming, making it hard to assess their impact and identify potential issues.

In this blog post, we will explore the factors that influence the ideal size of merge requests and provide practical tips to help you strike the right balance between granularity and comprehensiveness. Whether you're a seasoned developer or new to the field, this post will offer valuable insights into how to optimize your merge request process and improve your team's productivity.

There are several factors that can influence the ideal size of merge requests in software development. Those factors touch different areas of the software development process. Eventually, what they have in common is that they all affect the efficiency of the code review process and the quality of the codebase.

Complexity

The complexity of the changes being made to the codebase can impact the optimal size of a merge request. If the changes are simple and easy to understand, smaller merge requests may be appropriate. However, if the changes are complex, it may be better to break them down into smaller, more manageable pieces. So we need to ask ourselves, what is manageable? Manageable is a very subjective assessment, which leads us to the human factor of the code review process: The reviewer.

The Reviewer Workload

Reviewing code is a time-consuming and mentally demanding task, requiring the reviewer's undivided attention and concentration. Human attention span is limited, and sustained attention on a task can lead to cognitive fatigue and decrease in performance
This factor is very often heavily underrated in projects. Reviewers may have limited time and focus, for they are very often more senior developers in a team, already under heavy work load.

If a merge request is too large, it can overwhelm the reviewer, leading to a decrease in the quality and effectiveness of the review. Large requests can be challenging to understand and review, leading to mistakes and overlooked issues. In contrast, smaller merge requests can be more manageable and allow the reviewer to focus on specific changes, making it easier to identify issues and offer constructive feedback.

Hence, by taking the reviewer workload factor into account, teams can create merge requests that are optimized for efficient and effective code reviews, improving the quality of the codebase and increasing the productivity of the development team.

The Reviewer Availability

The previously made point is tightly coupled to the following one, namely that a merge request should be of a size that a reviewer can effectively review within a reasonable amount of time. If the request is too large, it can take a long time to review, delaying the merge process. And also reduce the motivation a reviewer might feel to pick up a review task. If you know that picking up that review task that has been sitting there for a few days will delay one's work for multiple hours, you will be less likely to choose the review over your own work.

Context

Arguably, the overall solution to our predicament could be to simply make merge requests tiny, maybe a few lines of code.
Enter once more the reviewer: A merge request must provide enough context to enable reviewers to understand the code changes.

Here the context of a merge request refers to the information provided about the changes being made, including the reasons for the changes, the overall objectives, and the impact on the codebase.

A merge request that is too small may lack the necessary information to understand the changes, while a request that is too large may be difficult to review due to the complexity and amount of information.

But how much context is needed then? So far, we have heard of complexity is affecting optimal size, reviewer workload effectively limits the size, and context demands a minimum size to make things understandable and approachable.

The Reviewer's skill level

If those were not enough constraints already, enter yet again the reviewer! Providing too much context in a single merge request can, in turn, make it difficult for reviewers to digest and understand. For example, a new developer may struggle to understand a large request that includes changes to many files or modules, while an experienced developer may be able to review a larger request more efficiently.

To ensure that merge requests are of an appropriate size, developers must consider the experience level of the reviewers on the team. For new team members or those with less experience, it may be more effective to create smaller merge requests with more focused context. For more experienced developers, larger requests with more comprehensive context may be appropriate. However, we have also determined that more experienced developers often experience higher workloads, leaving them effectively with less capacity for detailed reviews.

Boiling it down

In essence, after considering the various factors that influence the optimal size of merge requests, one can argue that smaller merge requests are generally better than larger ones. Smaller requests are easier to manage, more focused, and provide a higher degree of context, making them more effective for code review. They allow for more targeted feedback and faster iteration, which ultimately leads to a higher quality codebase.

One common denominator we have identified in the previous sections is the human factor in the equation to determine the ideal merge request size. This factor is hardest to estimate as it is dependent on your team constellation, it's skill level ratio, and also it's way of working.

If one thing is for certain, it is that there is no universal answer to our question. Each factor we have previously discussed affects another one in some way. While reading words like "smaller", "more manageable", "understandable and approachable" you quickly realize that most of the above arguments heavily rely on subjective reasoning. Eventually, the optimal size of merge requests varies depending on the complexity of the changes, the degree of interdependence between the code changes, the availability / workload and experience level of the reviewers and other team-respective factors.

In the end, the message this post is trying to convey is that each team should be aware of these factors:

• Complexity
• The Reviewer Availability
• Context
• The Reviewer's skill level.

Each team should sit down and make the question of optimal merge request size a point of discussion. Each team should
identify additional factors that might affect their optimal merge request size. And each team will finally come to a slightly different result. But most importantly, it will work for them! They made it work for them!

In general, we can state that smaller merge requests offer the best balance between granularity and comprehensiveness, providing the ideal platform for effective code review and collaboration. However, it is on the team in the end to determine what is small, what is manageable, and what is understandable and approachable.