Discover more from Dev Interrupted
The 11 Types Of Toxic Pull Requests (According To 4.5 Million Code Branches)
After reviewing millions of PRs, we've found the 11 that are dragging down your engineering team.
In the world of software delivery, pull requests are at the heart of collaboration between many engineering teams. Yet, while PRs are pivotal for ensuring code quality and fostering collective input, they've also become the leading bottleneck in developer workflows.
Poorly crafted or mismanaged pull requests can spell disaster for productivity. LinearB’s Engineering Metrics Benchmarks study analyzed the work of 2,000 dev teams and 4.5 million code branches, and found:
The average cycle time for a piece of work (first commit to deployment) is 7 days.
Half of all PRs are idle (e.g., no one is actively working on them) for at least 50% of their lifespan.
Cycle time and idle time doubled for pull requests of 200 lines of code compared to pull requests with 100 lines of code.
Having pinpointed this significant dip in developer productivity, researchers have uncovered the root of these subpar performance indicators.
Based on qualitative and quantitative analyses, developers and data scientists have identified four primary issues in PR management and 11 common types of pull requests that are particularly detrimental to workflow efficiency.
The 4 Root Problems in Engineering Workflows
Many organizations have no formal process for getting pull requests (PR) assigned.
No standardization or best-practice guidance for PR size.
Teams treat all PRs with equal importance despite their different risk levels.
Lack of visibility into PR context or how long it will take to review (until it’s opened).
With the root problems of poor PRs identified, engineers could now work on solutions to this massive hurdle in developer workflows. One of the most promising of these fixes has come in the form of Continuous Merge - the practice of automating the classification of pull requests in order to optimize the path to merge.
The 11 Types Of Toxic Pull Requests
Following their analysis of 4.5 million code branches, LinearB’s researchers found the pull requests causing 90%+ of these bottlenecks fall into 11 separate but related categories.
1. Small-PR Purgatory
Pull requests that languish in inboxes for days are all too familiar. What's worse is when these requests are merely for documentation changes. Quick updates get sidetracked, delaying even the simplest of tasks.
2. Pull Requests With Outdated Code
Submitting a pull request to a deprecated API? That’s not just redundant, but it also signifies a lack of synchronicity with the system’s current state. These types of PRs are simply clutter, causing unnecessary overhead.
3. Pull Requests That Require Documentation Research
Pull requests without proper documentation are like entering a room blindfolded. Without clear documentation, reviewers are left guessing the intent, leading to a whiplash in context-switching.
4. High-Risk PRs Without Adequate Review Support
A super-large, potentially hazardous pull request with only one reviewer? This is a ticking time bomb. Given the high-impact changes, these PRs should ideally have multiple sets of eyes to ensure accuracy and security.
5. Pull-Requests With A Domino Of Dependencies
Pull requests held up due to dependencies on other PRs can create a chain reaction of delays. This sequential waiting game can be a significant workflow roadblock.
6. Unfocused Improvements
Great pull requests have clarity of purpose. Those PRs that try to tackle multiple problems at once can be confusing, leading to potential oversights during reviews.
7. The PR With An Unattended Security Risk
What happens when a PR touches sensitive parts of the code, but isn't sent to your security team for review? This oversight could leave applications vulnerable, posing a grave risk to the organization.
8. Pull Requests That Bypass Team Experts
Every team has its developers responsible for maintaining specific areas of the codebase. PRs that should be reviewed by a domain specialist but aren’t miss out on crucial feedback and insights.
9. The Test-Less PR
Code without tests is like launching a boat without knowing if it floats. PRs that lack associated tests can lead to undetected bugs, compromising the application's stability.
10. Pull Requests Lacking Context (Estimated Time To Review, Unclear Description, etc.)
A pull request without an estimated review time or descriptive title can leave reviewers in a lurch. Not knowing the commitment required can lead to delays in picking up the request.
11. PRs That Rip Out Existing Code
Pull requests that delete code need extra attention. Often done in the name of increasing efficiency, these PRs can have cascading impacts and should be approached with caution.
Two potential solutions to toxic PRs
Depending on what side of the development debate you sit on, you may have heard of two potential solutions to the PR problem:
1. Pair Programming: Want to cut out toxic pull requests? You can choose to increase pair programming within your organization, setting up developers to work together on code with one engineer serving as the driver, while the second serves as a navigator or observer, providing live reviews of the code and switching their roles as needed. While pair programming increases the person-hours needed to deliver software, it has shown positive effects on defect rates in software. However, pair programming can also be challenging to implement on many teams, particularly in instances of remote pair programming.
Some great advice about pair programming comes from a member of the Dev Interrupted community, Ryan Latta. He recommends:
“Have a conversation before you work with your pair. The conversation should establish the rules, like how often you switch, and what's expected of the driver/navigator.”
Next, and of equal importance is to form some sort of agreement about your working style/preference. A great question to ask is, ‘If I see you struggling or making a mistake, when would you like me to correct you, and how would you like me to correct you?’”
2. Continuous Merge: For many teams looking to streamline their code-review workflows, implementing continuous merge can provide major improvement. Continuous merge is a process where, upon passing automated tests and workflow analysis, code changes are seamlessly integrated into the main branch based on programmable rules.
Research shows the implementation of gitStream, a free continuous-merge tool designed to optimize the transition from coding to deployment, improved software delivery cycle time by 61.07% while PR review time improved by 38.14%. This occurs due to customizable, programmable workflows that:
Attach 'estimated review time' tags to pull requests.
Categorize pull requests based on repository risk (low, medium, or high).
Implement auto-approve features for low-risk PRs.
Create quick “policy-as-code” guardrails.
How are you solving the pull-request problem?
The research on pull requests is clear: we’ve identified a crucial bottleneck in the workflow of modern software engineering teams. While LinearB’s team is focusing on developing continuous merge tooling to solve the challenge, organizations are taking a variety of approaches across the industry.
👉 How is your team solving their PR problems? Let us know by dropping a comment below or replying via email.
How Have Elite Engineering Teams Solved Toxic PRs? Download “The Continuous Merge Guide to Merge Standards: A Free Guide To The Merge Standards That Empower Policy-As-Code In Elite Orgs.”
The Continuous Merge Guide to Merge Standards covers where CI/CD falls short, the importance of establishing merge standards on your team, and how LinearB workflow automation can help.
Inside, you'll find:
A breakdown of Continuous Merge philosophy and its many benefits
13 of our favorite merge standards that enforce quality and boost efficiency
Tactical advice on how to implement merge standards on your team