Rethink Pull-Requests & Code Reviews

to become game stoppers - Part 1

What have git branches and a tree in spring in common? A lot of branches, and most of them stay forever.

Adobe Stock 418856391

Do you use Pull-Requests as a tool to control and review your development processes? If so, it's essential to prevent PRs from becoming a game-stopper. 

Do you know why PR and code reviews are part of your development cycle? Is it because of quality assurance? Is it because of missing trust in the people in the process?

For example, if you can't trust your developers to deliver quality work, it's time to work on that. And if your definitions need to be more precise, it's time to improve them.

However, these reasons alone are no reasons to put Code-Reviews as a hard requirement for the process.

It's essential to prioritize overall performance. If you add too many break points to your process, you can quickly stack up undone features. The more crucial negative side effect is that your developers must develop competence and maturity.

Instead, developers rely on someone else's responsibility before the changes get shipped, which isn't desirable in a deployment workflow in the long run.

Improvement and quality are relatively easy-wired into the deployment process, and you can take advantage of both worlds while keeping them separated.

Work on the team's Competence & Maturity Level.

Often, teams and developers rely so much on PRs in a group of people that they develop bad attitudes like irresponsibility. 

To automate your process and deliver quality, you need a constant flow with a simple goal to improve over time. The last bit is essential since it prevents your process from stagnating or worsening.

To improve, you need to remove breakpoints. Often, teams and developers rely so much on PRs in a group of people that they develop bad attitudes like irresponsibility. 

When the software delivery process stagnates, the backlog fills with open issues, and changes are stuck somewhere in nowhere, waiting for a review; you should finally admit that your workflow isn't working.

A common reason for this is a low maturity level and insufficient competence. So, let's take a look at it.

Increase maturity with a bold process.

We learn from mistakes. Failure is one of the richest information streams a human can receive. For some CTOs, VPEs, or developers, it may sound shocking at first, but it's overall better to be allowed to break things during production, then to be locked into a cage.

Sounds scandalous? Read on, think about it, and decide later.

• Remove breakpoints like PRs from the process.

• Boil down the scope of tasks to a minimum and ensure the outcome is understandable and testable by the developer working on it.

• If the developer needs to talk about the task or how to execute it, ensure there's always someone with time to respond. Avoid forcing the dev to switch jobs or contexts. Instead, get things done and out of your head!

• Leave a trace for your colleagues and link your changes in Git to your task or ticket. This is as good as a PR and a foundation for later team reviews.

• Complete the task, push it into the trunk, and let the CI/CD Pipeline do its thing, like building, testing, etc.

• Deliver or Deploy during or soon after the pipeline is done. At best, everything is automated.

• Optional: If the developer is convinced the task needs a review, than ask another person straight for help. There no need to push that task into the future. The overhead will reduce overtime, due to the spontaneous pairing sessions.

• Implement meetings where Code-Reviews happen in a team, not just between two. Share the learnings and make them visible for everyone.

This process is fast enough to keep it constantly running. It's bold enough to be challenging, and challenges will develop mindset and skills. It's even more effective in communication because you work with colleagues in the very moment when you need it and when your mind is wrapped around this topic.

The big difference is that this is only a short interruption. No one loses context. It's different from a traditional asynchronous Code-Review, where communication can happen days after everyone forgets the context.

Avoid a second backlog

The most important aspect is keeping your backlog in the backlog. So you can finish things continuously and only have a workload in the process, which you can handle as a team.

Will developers interrupt each other with this method?

This is a common question. This process aims to work on things and complete them in one take. However, this process only works with interruptions, too. For example, if a developer must consult a colleague during his development process, the colleague must switch contexts to help quickly.

The big difference is that this is only a short interruption. No one loses context entirely. It's different from a traditional asynchronous Code-Review, where communication can happen days after everyone lost context.

Regarding problems in production

A concern with taking Code-Reviews off as a requirement is bugs getting undetected into production. I understand this concern very well, but I always ask questions in response to that, like:

"Is it better to hesitate to push updates because of multiple unreviewed branches, not knowing in which state each of the 20+ branches is?"

"Is it desirable to have many changes scattered in many different branches across many developers, not knowing if the app is consistent anymore?"

"Do you know what you deliver when you deploy to production when everything is stuck for weeks, and you start to merge weeks-old branches?"

The chances of getting overwhelmed by its bureaucracy are high.

The critical aspect of human improvement.

By removing Pull-Requests as a deployment requirement, you take the risk as a team to push bugs and problems to production. But, think of the benefits for a moment. 

• Every developer will become self-responsible for delivering bug-free changes.

• The responsible developer needs to fix the problem in case of a bug today, not someone else someday. The issue will be reported soon after the update because of the short development cycle. The feedback for the developer is far more significant, as well as the learning effect.

• In the case of fire, the developer experiences an exceptional state: Stress. During stress, we learn best. This will reduce the chance of another outage over time, increase the maturity level, and, eventually, the developer's competence. In the long run, this hardens the process much more than naive ridgid breakpoints. Future stress will be avoided by that very effectively.

• Since there's no one left to point the finger at, the developer must be aware of their own doing. When everyone on the team works that way, helping each other answer questions and provide feedback will become the team's culture.

A competent and mature process isn't about automation but humans working together. It's about #mindest, #skills, and #culture; it's about responsibility.

Rely on the human instead of automation.

Team-Review code later and let developers link their Git commits to issues or tickets. This approach gives you enough time to work with your devs on quality later and go for refactoring. Then, instead of branching like a tree in spring, opt for a typical "develop" branch or trunk-based development. 

Developers should be responsible for their work; if they have questions, they must decide when to ask someone. Again, using a Slack group for a discussion during or later instead of two-way communication like a PR for this, is better.

So, consider implementing this solution if you need help with your PR process. It'll help your developers grow while improving overall performance. 

Conclusion

Required Code-Reviews are more a roadblock and a theory than a valuable part of the process.

PR & Code-Reviews are ubiquitous, and companies put them in place for their reasons. I understand this; I did the same for our reasons. However, the teams I have worked with directly always concluded that PRs and required code reviews are more a roadblock and a theory than a valuable part of the process.

Yes, we wanted to discuss code, best practices, and code improvements, but this is part of continuous enhancement and can be done more efficiently as a team. At some point, every team should come to an important insight:

We are professionals, and we can deliver. 

Think of other professions that you know from daily life. For example, if someone is providing you a service, no colleague is coming the following days to review for efficiency or mistakes. The person providing the service is a professional; thus, they are responsible for their results at that moment of execution, not later!

I wish you a great day!

Adrian