Pull Requests Are Herbie
Why waiting for the damned PR is the main productivity hit for software teams
You can still get my newest book Code-First Reliability for free if you become a paid subscriber. You can read all about it in the announcement.
I want to tell you a story about Herbie.
In Eliyahu Goldratt’s The Goal, just when Alex Rogo, the protagonist, is hitting rock bottom in both his personal and professional life, he leads his son’s class on a weekend overnight hike in the mountains.
That’s when we meet Herbie.
You know Herbie. He was the fat kid in your high school class. Herbie who always breathed through his mouth. Herbie with the fingers always stained in Cheeto dust. Herbie who has posted 1200 times on r/40kLore. Herbie who is “above sports”.
Herbie the kid who can’t see his toes.
[…] I see this fat kid. He already looks a little winded. Behind him is the rest of the troop.
“What’s your name?” I ask as the fat kid draws closer.
“Herbie,” says the fat kid.
“You okay, Herbie?”
“Oh, sure, Mr. Rogo,” says Herbie. “Boy, it’s hot out, isn’t it?”
Herbie continues up the trail and the others follow. Some of them look as if they’d like to go faster, but they can’t get around Herbie…
— The Goal, by Eliyahu Goldratt
The hike is a metaphor for a process, and Herbie comes to represent that component of any process that drags everything down. Herbie is the bottleneck. If success means getting to the bivouac place before the sun sets, Herbie is what stands in everyone’s way, blocking.
Your tendency is to try to ignore Herbie, placing him at the back of the queue. But the book’s lesson, of course, is that you have to focus your attention only on helping Herbie.
Because if your goal is to get everyone to the finish line, focusing on improving anything else is pointless.
I think about Herbie when I have to wait for my Pull Request to be approved.
I’d rather not be waiting. I’ve been working on this for a few days now, and I can sense it’s finished. I’m familiar with the issue at hand, and its surrounding context. I’ve tested enough on sandbox, and I’m ready to find out what production has to say about it. The solution is good enough for me.
But, in many tech organizations, that isn’t good enough.
Every company I’ve worked, and probably yours too, has established a few rules on Pull Requests and how to review them. I bet your manager expects some teammate to check your PRs, as they expect you to review theirs.
Pull Requests and their review is one of the most commonly accepted practices in software. Their goal is to control quality and feature delivery.
But the industry is wrong. We should get rid of PRs as soon as possible.
PRs are the Herbie of software development.
I’m Alvaro Duran, and this is The Payments Engineer Playbook. I’ve worked in tech long enough to know that PR reviews aren’t adding any value to any team that develops software for a living. You know that too, but only in your guts.
I bet that you’ve suspected that if we got rid of PRs altogether, quality would, not just not get worse, but it would even get better.
And in today’s article, I’m going to explain why.
This article will cover:
How The Goal’s metrics (Inventory, Operational Expense and Throughput) translates into the process of software development
What Pull Requests are good for, and why it doesn’t apply to you
What GitFlow tells us about software development
And a call to arms to revive the Continuous in Continuous Deployment
Enough intro, let’s dive in.