Pull Requests have become the backbone of the DevOps movement: the faster, the safer, the better. But the code review step, this systematic and synchronized communication task between humans, inherited from ancient times, slows down the overall development lifecycle for an illusion of safety. It’s time to introduce the Fluid Pull Requests paradigm.
Back in 2008, GitHub introduced the concept of Pull Request and, by doing so, significantly eased the contribution to open-source projects. For the first time, it had never been so simple for two strangers to collaborate on the same code base. At that time, the only purpose of a Pull Request was to provide a safe way to suggest code changes and discuss them in a collaborative interface.
More than a decade later, 170 Million [1] Pull Requests are created each year on private projects and 30 Million on public projects. So the concept has been embraced by the overall software industry and has become a de facto standard. During the same period, the DevOps movement took off, and nowadays, Pull Requests are the backbone of any automated SDLC (Software Delivery LifeCycle). On each Pull Request, many highly valuable tasks are fully automated: building, testing, static analysis to spot bugs, deployment on staging environments, etc. All this DevOps movement could be summarized in one mantra: “The faster, the safer, the better”. Starting in 2015, the DORA (DevOps Research and Assessment) [2] team has identified four key metrics that indicate the performance of a software development team. Three of those four metrics illustrate this mantra: Deployment Frequency, Lead Time for Changes, and Time to Restore Service.
So today, the lifecycle of a Pull Request should be a matter of a few hours, but it is always a few days or even a few weeks. Developers managed to automate many things, but we still have in the middle of each PR lifecycle a systematic and synchronized communication task between humans: the code review step. This inflexible code review step, inherited from 2008, slows down everything and is the main bottleneck.
Why do we keep on accepting to pay such a price? Why do we keep on pushing the stop-the-line button on each PR? Because no software, no static analyzer, nor AI will ever be able to formally prove that a code change is safe and maintainable. Our tooling will keep evolving to spot more patterns but proving the absence of problems is an unsolvable challenge. So we rely on humans to do so. But humans are even less efficient at spotting problems, tracking a flow of execution, or keeping more than 10 variables in our working memory. This is especially true when each PR has to be reviewed. Developers are progressively desensitized, and LGTM symptoms arise. We’re just accepting to pay the price for an illusion of safety.
So what do we suggest doing? As we said, Pull Requests are nowadays the backbone of the DevOps infrastructure, so we can’t work without them. Moreover, today there is no code analyzer to prove the absence of bugs or vulnerabilities, or critical design flaws, so we still need developers to review some code changes. The only problem is that this code review is done systematically, regardless of the context, and always involves synchronous communication between humans. Here is where the Fluid Pull Requests paradigm knocks on the door.
At the core of this Fluid Pull Requests paradigm is the capacity to adjust the code review process based on the sensitivity of the code change, either to lighten or strengthen it. This sensitivity evaluation must take into account several different elements. We can mention, for instance, the seniority of the developer on a code base, the complexity of the code change, or the history of changes. Based on this sensitivity evaluation, you can specify and automate several code review processes to automatically approve and merge, do an asynchronous review, assign several reviewers, and spot the most sensitive parts of the code changes. For instance, if a database migration script is added, it could be relevant to involve the database team, but only to approve this piece of code.
I guess you got it: Fluid Pull Requests is an extension of the Pull Request concept, to increase both the throughput and safety of delivery. We still rely on human review, but only when it’s the most relevant, and in a very driven way. Instead of reviewing everything every time, we only have the most critical changes reviewed by the most impactful reviewers.
References
[1] Octoverse Report 2021: https://octoverse.github.com/writing-code-faster
[2] DevOps Research and Assessment: https://www.devops-research.com/research.html
Top comments (0)