Pull Requests Considered Harmful

Pull Requests Considered Harmful Pull Requests Considered Harmful

In any software team you look nowadays, feature branching and pull requests (PRs) are a given. The git-flow style of development has taken the industry by storm. It is taught in most places and considered the way to deliver software.

This is a recent development, and it wasn’t always like that. It is not the only way to code and it can create a negative impact.

Firstly, git-flow / feature branching / PR based development was envisioned for Open Source Software (OSS). Those are very different from your average all-in-a-similar-timezone collaborative product software team. Brian makes this point in a much clearer way:

OSS software development therefore makes sense as an asynchronous, big-tent process. Code is submitted and reviewed intermittently. People can reasonably work on somewhat different copies. Integration can be safely deferred.

However, most paid teams are the opposite: membership is well-defined, members are vetted and (hopefully) mentored, and everyone’s being paid to show up.

And this is not a new topic. Many before me have talked about it. There is even a website for it at trunkbaseddevelopment.com.

Why am I discussing it now?

It’s a personal interest. I had never created a PR until 6 months ago. My nearly 13-year career in tech started at ThoughtWorks, where Trunk Based Development was continuously promoted. Afterward, I worked in an engineering team at my own company and rarely created branches.

I’ve always worked in teams from 5 to 40 engineers who would all commit to master. That was never a problem.

Moving into a bigger technology company, I encountered a constant pile of PRs waiting for review. Engineers working on multiple items simultaneously submit PRs, get blocked, and move on. This workflow creates stress.

What’s wrong with feature branches and PRs?

This working model was designed for OSS, not the average commercial team. PRs slow teams down and can create patterns that reduce collaboration and increase technical risks.

It’s not black and white. PRs can have benefits. But we should consider the price we are paying for them and make it more effective.

I will address specific issues in a series of mini posts, starting with The Snail Pace of Pull Requests.

Enjoyed this post? I write about leading effective software engineering teams. Subscribe to stay in the loop.