Two developers are working on the same project, after a few days of banging their heads against a wall, both have a breakthrough. Each is making amazing progress with its own part. They’re motivated, inspired, and in the zone. The dream of every project manager.
And yet, unbeknownst to everyone involved, this kind of situation can lead to a dead-end. Both developers are so into their respective parts of the project that they both completely miss the fact that the other is waiting for a code review. This is the Pull Request paradox in a nutshell.
Understanding Pull Request
Once upon a time, there was a movement called Open Source Software. The idea was simple and yet revolutionary: by making the source code of a software free to use and share, more developers and engineers could work on it and improve it.
We could take and repurpose pieces of code, or propose changes and bug fixes to improve on existing software. It was collective engineering at its earnest. And for a time it worked. But as the internet grew, and more people got involved in software development, open-source had to adapt.
How do you organize feedback from dozens of collaborators? What about hundreds? Or even thousands? Projects like PHP were nodes of activity with passionate communities and ingenious developers. From the outside, it may seem like something great, but for the people in charge of the source code, it was a nightmare.
The solution was called GitHub, and Git would grow in very little time to become the norm, not only for open source projects but for the business world as well. Inspired by mathematical trees, GitHub organized the workflow of developers worldwide, providing a powerful management tool to work with source code.
In essence, GitHub works by having a main branch from which developers can fork the project, in other words, create a “personal copy”. That way, a developer can work their magic without the risk of breaking the code on the main branch.
At any point, a developer can push their work to the main branch, but to prevent mistakes or unintended changes, the owner of the branch can go over the changes and decide if they accept them.
When a developer pushes their branch they create a “pull request” it’s a message letting other developers know that they want their work to be merged to the main branch. In essence, Git is more than a repository, it’s a communication framework for software engineers.
When Communication Fails…
The data science team at LinearB went over 733,000 pull requests and 3.9 million comments from over 26,000 developers and found some very interesting information:
The average pull request review time sat around 4 days and seven hours. If we take into account that 50% of all pull requests remain idle for about 50% of their lifespan, that means that on average a pull request sits untouched for about two days.
That might not seem like much if the developer can work in other aspects of the project in the meantime. But, if they need the code review, that’s a lifetime. 48 hours can be devastating when you lose your focus. I can’t count the number of times I’ve revisited my code after a couple of days only to contemplate it as if it had been written by an Alien.
The longer we sit idle the harder it is to answer questions about the code down the line. The higher the cognitive load of returning to work on that code, the odds are higher that we could forget something important that could lead to errors and bugs down the line.
If we’re well aware of the problem of idle requests, then why are they so frequent? Because ironically software development is a social paradox, we’re islands in an interconnected archipelago.
Software is extremely complex, and meeting deadlines usually means that we have to work as a team, which is great since multiple perspectives often lead to a much better and more reliable outcome.
But at the same time, some aspects of our routine can be extremely lonesome. All software developers have experienced being alone with their ideas, usually with headphones on, and nothing but the company of a computer screen.
It’s easy to forget that we’re part of something bigger and that others depend on our input and expertise. Unfortunately, it’s painfully common that a developer leaves a request hanging “for a few more minutes” or “until this is done”. After all, you wouldn’t want to break your workflow.
Breaking the Paradox
How to solve a Pull Request paradox? This is a problem that’s more frequent now that working from home is becoming a popular alternative. In an office, you can just go to your fellow’s workstation and ask for their input or review, and most people would be more than happy to oblige.
But messaging tools like Teams and Slack are easier to ignore or postpone, just like emails. One solution is to promote a culture that relies on calls or other voice-over IP solutions. In other words, trying to bring a bit of that “face to face” interaction in our virtual environment.
Some people would recommend adopting a true continuous delivery methodology that does away with pull requests altogether. And while that may sound like a great solution, in theory, it comes with its own fair share of problems.
Most software developers will agree that pull requests are a great way to receive feedback and input from your coworkers. It’s especially valuable if you are working with junior developers who stand to gain a lot from a code review by more experienced team members.
Pull Requests also bring something to the table that no form of automation can provide just yet, human ingenuity. Nothing beats a set of fresh eyes going over our code. The questions and comments from this interaction usually help us look at the problem from a new perspective and grow as professionals.
In other words, a fully automated solution can work for an expert team that has been working together for a long time. Fresh teams or teams with newcomers to the business can use pull requests as a way to keep the creative juices flowing and to train juniors.
For those teams, it’s important to foster a culture that values Pull Requests and quick responses. A method that usually helps is to measure idle time as a KPI, this brings the focus back on the importance of quick responses.
Another way to improve your request time is to promote smaller deliveries. When a reviewer sees a massive list of changes they’re less likely to make time for the review. Humans make judgments based on the amount of effort they have to invest. The less effort, the more likely they are to do it right away.
We are Connected as a Team
The Pull Request paradox is an apt reminder that software developers are heavily reliant on one another. Something that we often forget in the heat of the moment, our actions can have far-reaching consequences, and like a machine a team is only as efficient as the slowest part of the system. Fortunately, unlike machines, we’re humans, capable of growing, adapting, and finding connections with others.
