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 (highlighted below).

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, physically or online.

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

Why am I discussing it now?

It’s a personal interest. I had never created a PR until 6 months ago. My almost 13 year old career in tech started at ThoughtWorks, where we continuously promoted Trunk Based Development. After that I worked in an engineering team in my own company and don’t remember ever creating a branch.

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

Moving into a bigger technology company, I was hit by a constant pile of PRs waiting for review. And with engineers working on many things at the same time because they are submitting PRs, getting blocked and moving on. That stresses me out.

What’s wrong with feature branches and PRs?

So this working model was designed for OSS and not the average commercial team. What is the problem with it? Well, there are a few. PRs slow teams down, and can create working 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 some of the issues I’ve found in a series of mini posts.

Let’s start with The Snail Pace of Pull Requests. More to come.