Have you ever had an extreme reaction to someone leaving a comment on a Pull Request (PR)?
Why was that? Was it something about your mood that day? Was it that you feel attacked and don’t like it? Is it the frustration with the speed of the PR process? Something else?
PRs are divisive. They are blockers to releasing code, but then they also invite the option to review, which should, in theory, improve quality. But how often do PRs just get signed off without much attention being paid to them? And when you’re trying to push something which you consider low risk to test a theory, do you ever get blocked by someone with potentially valid complaints about quality?
PR as a Limiting Factor
Gitflow (which underpins the PR process) is in theory deprecated and yet so many places are still doing it. Why is this?
When viewed through a long lens, it could be argued that PRs improve quality. But when they slow down our release process and cause friction in the team, perhaps they should be replaced by automated testing.
PRs help to effectively share information about what’s happening in the codebase without explicitly setting up a meeting. In this case they serve a purpose. However, sometimes working with them reminds us of our own shortcomings and our own preferences. We need to justify ourselves and our opinions with someone else. Despite having worked in the industry for almost thirty years, I still find it very difficult to have this argument and I don’t enjoy it. However I know that there are very good reasons for doing things in other ways, I just can’t always express them. Therefore the PR process can be a real blockers to experimentation and creativity, as well as blockers to those individuals who don’t want to raise their voice or argue with more dominant team members.
Keeping and Open Mind
We all live in imperfect worlds and imperfect software development lifecycles but it’s important to keep an open mind about our release lifecycle. If our process is stifling creativity and important voices, how can we modify it to make that less of a point of friction?
Therefore, it’s good to approach the PR process with an attitude that they may be a current, necessary, agreed part of our process but perhaps it won’t always need to be that way?
Striving for a better solution with more effective automated testing, perhaps we open the door for more experimentation and more freedom, or perhaps it goes the other way and provides us only with more guardrails to our applications?
Perhaps the time axis has been ignored for too long for these important parts of our SDLC. Not least the social impact of PRs and their impact of time to release and software quality.