Rethinking Pull-Requests & Code Reviews–The Conclusion

Preface - Who should read this?

Is it worth questioning Pull-Requests and Code-Reviews? This article tackles whether we should weave these into our dev cycles and company culture. It’s a blend of my past writings and feedback from seasoned tech pros like Senior Developers and CTOs. We’ll explore varied viewpoints, weighing the good and the not-so-good.

While I lean towards Continuous Delivery, I aim to give a balanced view. So, whether you code or lead tech teams, this read will offer clarity on Pull-Requests, Code-Reviews, and Trunk-based development. Dive in!

Index of this article

Part 1: Brief Overview of the Current State

Part 2: The Problem with a Code Review Backlog - Why should we rethink branching?

Part 3: Addressing Audience Feedback

Part 4: Industry Perspectives on Modern Development Strategies + Conclusion

Part 1: Brief Overview of the Current State

Code reviews and pull requests (PRs) have become standard practices in the software development lifecycle. They ensure high-quality code, encourage collaboration, and prevent bugs. However, it's becoming evident that these practices can also introduce challenges like stagnant review backlogs, inefficiencies, and compromises on code quality.?

So we are talking about a method intended to improve quality, yet I received feedback that the result can be quite the opposite. In this article, I want to highlight that readers and listeners of my audience have experienced different software development methods. So, let's get into it!

What are Pull-Requests and Code-Reviews?

The "Pull Requests" concept is closely linked to GitHub, which introduced the feature to support code collaboration. While it's hard to attribute the invention to a single person, GitHub co-founders Tom Preston-Werner, Chris Wanstrath, and PJ Hyett played critical roles in popularizing it. The feature is now widely used in other version control and hosting platforms and is sometimes called Merge-Requests, like on Atlassian's BitBucket.

A Pull Request is generally a way to review code changes before merging them into a specific branch. This practice serves as a quality check and a platform for collaboration and knowledge sharing among team members. It has become integral to modern software development workflows, enabling developers to discuss changes, identify bugs, and refine code.

Polls: Do You Use Pull Requests and Code Reviews?

I polled developers about their use of PRs and code reviews. Here are the results:

• PR + Code Review (Happily): 70%
• PR + Code Review (Unhappily): 17%
• Trunk Based Development: 9%
• Other: 4%

23 votes

The poll also revealed that several participants who didn't vote in the survey were inclined towards trunk-based development (TBD) , adding further weight to its emerging popularity.

Finally, in Tech Leader Slackgroups or WhatsApp Groups, the tendency was subjectively clear on the PR+Code Review Side.

Subjective Result:

Based on my current knowledge base, most developers are using PR + Code Reviews in one way or another. Yet, a significant portion are using trunk-based development.

Polls: Trunk Based Development amp; Pull Requests

Pull Requests and Code Reviews aren’t required for Trunk Based Development since TBD is based on making changes directly to the trunk or with short-lived branches. The latter approach requires discipline but mitigates problems with very decentralized non-core groups of developers.

In trunk-based development (TBD), would you prefer direct commitments to the trunk or short-lived branches that merge quickly?

• Direct changes to trunk 37%
• Branch merged after PR+Review 44%
• Branch without PR+Review 14%
• Other (comments) 4%

91 votes

Discussion between Senior Developers

Based on the poll I conducted about trunk-based development (TBD), I received various insightful comments from tech professionals that enriched the discussion. ángel del Blanco Aguado stood out for endorsing pair programming, which he feels can be effectively combined with direct commits to the trunk or short-lived branches, depending on the situation.

Paul Hammond made a compelling case for using very small branches, arguing that this approach strikes a balance and provides psychological safety for developers. Richard Smith pointed out that while direct commits work well for smaller teams, transitioning to a more structured approach involving PRs and reviews becomes necessary as a team grows.

James Galyen emphasized flexibility in development workflows, advocating that the chosen method should ultimately serve the interests of customers, developers, and the business.

Interested in Reading Part 2, "The Problem with a Code Review Backlog - Why should we rethink branching?" and Part 3, "Addressing Audience Feedback"?

? + 3 Videos about Pull-Requests, Code-Reviews, and how I manage to keep a constant progress running.

?? Keep on read Part 2+3+4 on my Blog