How the size of a Pull Request can impact developer experience?

Code reviews are a critical component of the software development process that helps maintain quality and ensures that new code integrates seamlessly into an existing codebase. 

However, the size of pull requests (PRs) can significantly impact the efficiency and effectiveness of these reviews. 

The size of a PR in many scenarios becomes a major factor that affects the reviewer's experience and eventually the overall health of a software project.

What's the best size for a PR?

A large body of research has shown that code reviews are the most cost-effective way of finding defects in code. Studies show that PRs under 105 lines of code work best. 

This benchmark is more than just a number. It reflects a deeper understanding of a developer's experience during the review process. But why is the size so crucial, and what happens when PRs become too large or remain within the recommended range? 

Small vs. Big PRs: What's the Difference?

The experience of reviewing a PR varies significantly depending on its size. Let's compare reviewing a 105-line PR to one that's 400-800 lines.

Small PRs (Under 105 Lines)

1. Better Focus: Reviewers can look at details more closely, giving better feedback.
2. More Sharing: Small PRs mean code is shared more often, so everyone knows what's going on.
3. Saves Time: Reviewers spend less time on each PR, so they can do their own work too.

Large PRs (400-800 Lines)

1. Too Much to Handle: Large PRs can be overwhelming and don't get the attention they need.
2. Surface-Level Reviews: Often, PRs with large lines of code change gets a fast check, which might miss important issues.
3. Team Disconnect: Infrequent, bulky PRs can lead to team members being less informed about each other's work, creating gaps in understanding.

In theory, PR size is important. But in real life, it's even more crucial. 

Large PRs can slow things down and stress the team resulting in delayed releases and making things harder for everyone. It's like when you had a big book to read for school. Many would choose Cliff Notes instead because the whole book was too much. 

Small PRs are like short articles that get full attention, while large PRs are like big books that people just skim through.

The Developer Experience: More Than Just Speed

While delivering work quickly is important, the experience you provide to your developers and engineering team is equally crucial. The size of PRs can significantly impact this experience. In a highly competitive market, fostering a healthy developer environment is key.

Small, regular PRs make reviews better and help the team work well together.

How does Harness SEI help in measuring the PR activity?

In managing the challenges of PR sizes and their impact on code reviews, Harness SEI helps in solving the problem of measuring PR activity using SCM reports. 

SCM reports provide a detailed analysis of activities within SCM tools, offering insights into:

• Individual developer contributions.
• The volume of rework and other code changes.
• Lead time and activities related to PRs and SCM issues.
• Review collaboration.
• Most active repositories and files.

These reports can be customized based on project, repository, time range, and other data points, depending on your SCM integrations. 

The SCM Committers Report is particularly useful for evaluating individual developer contributions. It provides a clear picture of each committer's involvement in the Collection, displaying:

• The number of PRs they have worked on.
• The number of commits they've made.
• The number of lines of code they have contributed.

This information is crucial for ensuring accountability and transparency, effective project management and resource allocation, and evaluating the performance of developers or teams.

Engineering teams can leverage Harness Software Engineering Insights to first baseline the people, processes and tooling bottlenecks and then drive a continuous improvement process. To learn more, schedule a demo with our experts.