Rethinking Pull-Requests & Code Reviews in Modern Development Workflows
The Summary & 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
Note regarding correctness: James Galyen hinted that this poll could have been misleading since PR+Code Review and TBD together are possible. That’s true. During the next week, I will ask these questions in the context of TBD again and update this section accordingly.
The poll also revealed that several participants who didn't vote in the survey were inclined towards trunk-based development (TBD)1, 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 & 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 Aguado2 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 Hammond3 made a compelling case for using very small branches, arguing that this approach strikes a balance and provides psychological safety for developers.
Richard Smith 4 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 5 emphasized flexibility in development workflows, advocating that the chosen method should ultimately serve the interests of customers, developers, and the business.
Additional Views on PRs and Code Reviews for Learning and Collaboration
Additional comments from the poll further expanded the scope of the conversation. One senior back-end software engineer expressed that PR+Review mechanisms can reinforce collaboration when changes are made to the master branch.
A consultant software developer echoed this sentiment, stating that pull requests and reviews are excellent code quality and learning tools. These viewpoints reiterate the importance of considering various development practices, like pull requests and code reviews, as valuable components in a balanced Trunk Development strategy.
Going Straight: Going straight to Trunk and avoiding making PRs
Next to the voices for Pull-Requests, there were clear voices6 against Pull-Requests during TBD and Pull-Requests in general, which refers back to the original topic of this article. Instead of reviewing via PRs, which are irrelevant in the sense of TBD, Andrea L. 7 made an exciting contribution.
In Continuous Integration, it's crucial to understand that there are viable alternatives to pull requests for facilitating code review. Among these, Pair Programming stands out for offering real-time, continuous feedback during the coding process itself. Then there are Periodic Reviews, a structured approach where the team allocates specific times to review all recent changes. Last, Pipeline Approvals insert a human review stage post-integration and automated tests, allowing us to scrutinize code that has already met technical criteria. These methods maintain and potentially enhance code quality, all while keeping the software delivery process agile and efficient.
Source: “Why your team doesn't need to use pull requests“8
A misunderstanding when it comes to Continuous Delivery or TBD
Continuous Delivery (CD) and Trunk-based Development (TBD) are often misunderstood. CD is about always being ready to release, not the frequency of releases. TBD focuses on high-frequency integration, not the elimination of branches or Pull-Requests (PRs).
The ultimate goal for both is to deliver high-quality software efficiently. Rather than debating the use of PRs or branches, the focus should be on creating an environment that supports continuous integration, making it possible to release valuable software early and often.
Subjective Conclusion after Audience Feedback
These varied perspectives underscore that there's no one-size-fits-all approach to TBD; instead, it's about finding what works best for your unique team and project circumstances.
Note: The following list can be controversial; pros and cons could be switched in different contexts. Please consider this a rough subjective list.
Pros for PR/Code Reviews:
Quality Assurance: Pull requests enable multiple developers to scrutinize code changes, enhancing the overall quality.
Collaboration: The PR process encourages team members to collaborate, share expertise, and establish coding standards. Especially in decentralized groups of developers, it can work well.
Pros for Trunk-Based Development (TBD):
Speed: TBD allows for faster integration and reduces the delays associated with PRs, enabling a quicker development cycle.
Agility: TBD is adaptive, making it easier to pivot or adjust to new requirements without the overhead of PR management.
Foundation for Continuous Delivery: Without the practice of TBD, CD will become hard, if not impossible, to achieve.
Cons for PR/Code Reviews:
Delays: Waiting for PR approval can introduce delays, especially if not many team members are available for review.
Context Switching: Having to review code means developers have to take time away from their own tasks, leading to potential context-switching overhead.
Merge Conflicts and Outdated Branches: When working with long-lived branches, we often see code becoming obsolete or dangerous to merge.
Cons for Trunk-Based Development (TBD):
Risk of Errors: Direct commits to the trunk can introduce errors if not adequately tested, especially in larger teams.
Lack of Formal Review: The absence of a mandatory review process can potentially lead to lower code quality, particularly for less experienced teams. Instead, a mature engineering culture, sometimes called more experienced teams, must review code for quality assurance.
Final Thought:
The choice between PR/Code Reviews and Trunk-Based Development depends on various factors, such as team size, project complexity, and the development culture. Both methods have their merits and drawbacks, and the best approach may involve a balanced strategy tailored to your specific needs.
Part 2: The Problem with a Code Review Backlog - Why should we rethink branching?
Adrian: The following Part is a summary of my, rather bad, experience with PRs and asynchronuous code reviews and why I prefer continuous delivery.
Initially, I started to write articles about this topic because I faced during my Fellowship-Advisory sessions that many teams use PRs as their standard technique while working is stacking up because the reviews weren't executed fast enough. There were two common reasons for that:
Too complex and often incomplete tickets, which made a review problematic and time-consuming
Overburdened developers; resources needed to be improved to work down the stacked Pull Requests.
As a result, the process became stagnant, the branches outdated, and the developer's context was lost when it finally came to a review. These problems resulted in a general hesitancy to deploy code because developers became insecure after losing the overview.
The Cost of Delay in Code Reviews
Having a backlog in code reviews doesn't just slow down development—it also delays the value we deliver to customers and stakeholders. Think of it like a traffic jam: it impacts everyone and disrupts smooth progress.
Viewing code reviews as a necessary but asynchronous task can create bottlenecks in our delivery process, holding back value that could be delivered promptly.
The mature and competent alternative:
Instead of this approach, we should build a culture focused on competency and maturity. By 'maturity,' we mean responsible handling of changes made to version control. These changes are effectively pushed to clients, so a responsible mindset is crucial.
'Competency,' on the other hand, involves judging whether changes are fit for delivery. If we're uncertain, seeking immediate input from colleagues, perhaps through pair programming, is essential. This ensures that we maintain a high-quality code base while avoiding unnecessary delays.
Impact on Stakeholder Relations
When projects get delayed, stakeholders get anxious. This often leads to undue pressure on development teams to speed up, resulting in rushed jobs and compromises on quality.
Having the business colleagues, the product owner, or the clients asking you about the progress every few hours because many things became overdue is a downward spiral. The mental stress affects the quality and lures us into taking shortcuts to deliver somehow. This is one of the sources of technical debt we should avoid at all costs.
The desire to clear backlogs fast can sometimes compromise the quality of the code being pushed. As the old saying goes, "Haste makes waste."
Inefficiencies in the Review Process
The code review process can suffer when misalignments occur between those requesting and performing reviews. This can lead to lengthy discussions, diverging opinions, and delays in merging code.
Since we are professionals, we should be able to decide whether a change or a feature can be delivered. Of course, the scope of requirements should be small so that a single developer can assess them and decide that a feature is done.
Code Reviews aren’t necessarily needed in a mature and competent environment as a requirement to deliver. Quality assurance in software development is about the continuous process, not the lines of code.
Part 3: Addressing Audience Feedback
The Holy Grail Syndrome
The feedback shows that many teams view PR + Code Reviews as the epitome of collaboration. While these practices have merits, clinging to them without considering alternatives can be limiting.
The following part is a very important one in my opinion; it’s about context. We always need to consider contextual circumstances.
Author’s note.
Jonathan B. C 9 cautions against adopting absolutist positions. He emphasizes the importance of considering context, project size, team size, and industry when selecting a development methodology.
Losing the Big Picture
Focusing solely on small, incremental changes might make developers lose sight of broader goals. Reviews should facilitate development, not restrict it.
Kornel Dubieniecki highlights the importance of code reviews for sharing knowledge and keeping changes atomic and easily revertible. He argues that well-managed code reviews contribute to overall project clarity. 10
This is an interesting point that Kornel raises. However, I believe the key is to make it unnecessary for a developer to understand the big picture, as this could result in mental overload that distracts from the essentials. I often faced this issue myself when transitioning from a hands-on tech lead to a CTO role; I tried to grasp the entire landscape while only working on small aspects. The result was a noticeable lack of focus.
Author’s note.
The Team Dynamics
Feedback emphasized fostering a positive mindset and using methods like pair programming. This shows a need for a team culture grounded in communication, learning, and enhancement.
Itzy Sabo emphasized the importance of aligning with team members and seeking guidance to avoid surprises during pull-request. 11
Absolutely, communication is the linchpin of successful teamwork. Reviews are indeed a form of communication, designed to ensure quality and coherence. By prioritizing effective communication within a team, we can nurture an environment of continuous learning and improvement. Establishing a culture that values both learning and enhancement paves the way for stronger team dynamics and better outcomes.
Author’s note.
Complexity as a Hindrance
Audience feedback also highlighted the pitfalls of complexity. A culture of keeping things simple and communicative is crucial for avoiding complications.
Kenny Cruden advocates for trunk-based development, stating that branching for QA introduces duplicate effort and increased complexity. 12
Exactly, simplicity and clarity often lead to more efficient and effective processes. I resonate with your perspective. I remember the days of Subversion where things were more trunk-centric. However, with the advent of Git, we saw the emergence of GitFlow, which, while powerful, can become a complex web if not managed well—almost like a Halloween tale, as you aptly put it. Embracing Continuous Delivery and Trunk Based Development can indeed shift our focus back to a culture that prioritizes delivery and streamlines processes, rather than getting bogged down in unnecessary complexities.
Author’s note.
Alternatives to Traditional PR & Code Reviews
Emphasizing CI/CD
A well-structured CI/CD pipeline can act as a safety net, catching issues before they become major problems, thereby reducing the need for extensive code reviews.
Richard Smith advocates for reviewing work without causing delays. He suggests a pipeline for basic-level deployable changes or synchronous reviews before merging. 13
I'm particularly fond of this approach. It's especially noteworthy that many changes are so minor they don't even require reviews. In such cases, automation suffices. When reviews are necessary, synchronous evaluations work well. Personally, I always advocate for including a "green pipeline" in the "Definition of Done."
Author’s note.
Developers Taking Ownership
Platforms like DigitalOcean's App Platform 14 empower developers to take charge of their code from development to deployment, simplifying workflows. The original idea of the DevOps Movement or Culture plays an important role in deciding whether to go with async Code Reviews or not. DevOps includes ownership and responsibility, which links to maturity and competency.
Of course, it must not be DevOps; this can be applied to pure dev teams supported by platform engineering teams. However, DevOps is a holistic and important example to consider in decision-making.
Responsible Pushes
By acting responsibly and consulting peers when necessary, developers can make the code review process smoother and more efficient.
James Galyen proposes self-approvable pull requests and trust for efficient development, complemented by adjustable code coverage and pipeline tasks. 15
The idea of self-approving is excellent. I like it because it underlines the importance of responsibility. Of course, this can be done with or without PRs.
Asynchronous Code Reviews
Part 4: Industry Perspectives on Modern Development Strategies
Summary of Professional Insights
Experts in the field, such as Itzy Sabo and Richard Smith, have stressed the importance of aligning team efforts and adopting a context-specific approach to development.
Conclusion
Balancing Tradition and Innovation
As the software development landscape evolves, teams must adapt by balancing tried-and-true methods with innovative practices.
Stan Ivanov 16 and Paul Hammond 17 support trunk-based development, with Stan recommending starting with new features or services before gradually adopting it for legacy code. Paul sees it as a prerequisite for continuous integration and emphasizes the importance of clean code.
Absolutely. Trunk Based Development (TBD) goes beyond just pushing changes to the main branch. It's about fostering a mature culture and acquiring the essential skill sets. At its core, TBD embodies a mindset of continuous delivery, making it the foundation of the entire development process.
Author’s note
The Importance of Team Culture and Communication
A team culture that values open communication, continuous learning, and collective problem-solving is the key to efficient and effective development.
Shahar Halutz focuses on the significance of gaining context and a broader understanding of the system through open communication. Marcel Hageman shares his experience, highlighting the importance of quality-focused reviews and good, committed messages. 18
In essence, this article delves into methods of communication and delivery. But it's pivotal to remember that whether through TBD or traditional branches and code reviews, the core focus is on improvement. It's a journey of continuous learning and enhancement that aims to uplift individuals, teams, and the broader company.
Author’s note.
Final Thoughts
Should we consider Pull-Requests obsolete and shift entirely to trunk-based development?
After discussing with numerous developers over the past few weeks, I believe the answer isn't so straightforward.
Each developer who contributed to this discussion brought a unique and honest perspective rooted in their experiences. Unsurprisingly, these viewpoints varied greatly.
For me, the crux of the matter lies in context. We must consider who we are, our current situation, our constraints, and the areas we must address.
Choosing a particular development approach today doesn't cement it for the future. As developers, we encounter diverse methodologies across different teams and companies.
For those in leadership roles, like tech leads or CTOs, evolving insights and the growth of their teams might prompt them to adapt or change direction over time.
We are developers; we develop not only code, but we also develop ourselves and our methods. We shape our skills and cultivate mindsets of learners. Thus, we won't remain as we are today; and that's great!
Mantra
Thank you so much for reading my article and participating in the discussion. I sincerely hope to have you in the next discussions with me.
Adrian 👋
https://minimumcd.org/minimumcd/tbd/
https://www.linkedin.com/in/angeldba/
https://www.linkedin.com/in/paul-hammond-bb5b78251/
https://www.linkedin.com/in/richard-smith-7297565/
https://www.linkedin.com/in/james-r-galyen/
https://www.linkedin.com/feed/update/urn:li:ugcPost:7117535802238095361?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7117535802238095361%2C7117634542957387776%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287117634542957387776%2Curn%3Ali%3AugcPost%3A7117535802238095361%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7117535802238095361?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7117535802238095361%2C7117634542957387776%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287117634542957387776%2Curn%3Ali%3AugcPost%3A7117535802238095361%29
https://infrastructure-as-code.com/book/2021/01/02/pull-requests.html
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114575239186894848?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114581646720282625%29&replyUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114587053152972800%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114581646720282625%2Curn%3Ali%3AugcPost%3A7114575239186894848%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287114587053152972800%2Curn%3Ali%3AugcPost%3A7114575239186894848%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114881009216536576?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114881009216536576%2C7114955551163174912%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114955551163174912%2Curn%3Ali%3AugcPost%3A7114881009216536576%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7113060017540317184?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7113060017540317184%2C7113062863736307712%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287113062863736307712%2Curn%3Ali%3AugcPost%3A7113060017540317184%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114575239186894848?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114581646720282625%29&replyUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114590807843557376%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114581646720282625%2Curn%3Ali%3AugcPost%3A7114575239186894848%29&dashReplyUrn=urn%3Ali%3Afsd_comment%3A%287114590807843557376%2Curn%3Ali%3AugcPost%3A7114575239186894848%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114881009216536576?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114881009216536576%2C7114962007304359936%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114962007304359936%2Curn%3Ali%3AugcPost%3A7114881009216536576%29
https://cloud.digitalocean.com/account/referrals?i=0f7ca3
https://www.linkedin.com/feed/update/urn:li:ugcPost:7117535802238095361?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7117535802238095361%2C7117539277395148802%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287117539277395148802%2Curn%3Ali%3AugcPost%3A7117535802238095361%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114575239186894848?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114601273647054848%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114601273647054848%2Curn%3Ali%3AugcPost%3A7114575239186894848%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7114575239186894848?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7114575239186894848%2C7114581646720282625%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287114581646720282625%2Curn%3Ali%3AugcPost%3A7114575239186894848%29
https://www.linkedin.com/feed/update/urn:li:ugcPost:7115659729049116673?commentUrn=urn%3Ali%3Acomment%3A%28ugcPost%3A7115659729049116673%2C7115711741526687744%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287115711741526687744%2Curn%3Ali%3AugcPost%3A7115659729049116673%29