Pull Requests
Last Updated: June 2025
Pull Requests are a proposal to merge a set of changes from one branch to another. They emerged from the world of open source and are optimized for low-trust, low-communication environments. These are a form of discontinuous integration.
If worker busyness were the measure of software productivity, then pull requests would be well suited to the task. But we know that’s not how quality and productivity are formed. “Watch the work product, not the worker,” says Donald G. Reinertsen. In this context, that means watching how long it takes from starting a change to its deployment (Lead Time for Change).
**Why do people use Pull Requests?**
- Provides a formal stamp/signoff with traceability
- Forces all code to be reviewed
- Tooling minimizes apparent effort and streamlines the process
- No collaboration or face-to-face meetings required
**Weaknesses to Pull Requests include:**
- Typically only spot surface level problems, missing structural level issues.
- Lead to a false sense of security and reduced sense of accountability
- Increases the effort per developer as they carefully wordsmith feedback
- Changes often require 2-3 rounds of feedback and change, which increases the time to production
- Can erode culture by discouraging live interactions and conversations
- Inherently ineffective and inefficient due to emphasis on minimizing human interaction
- Back and forth interruptions slow both the code author and the reviewer
- Delay the improvement process to the end instead of building it in from the beginning
- Represent Work in Progress, and we know that increases cycle time and reduces throughput in the system
**What to do instead:**
- Pair programming: active review that builds quality into the product from the start
- Ensemble programming: collaborative development with an effective work-in-progress of one, eliminates need for post-facto reviews and rework
- If pull requests must be used, reduce the size of the average change; prioritize finishing other people’s pull requests before doing your own work; prefer conversations over written feedback.
**Build Quality in**
In the long run, it is always faster to build quality in from the start than to beat it into the system at a later date.
