Avoid Pull-Requests & Code Reviews to become game stoppers.

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

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

Are you aware of 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 aren't clear enough, 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 important to?keep overall performance as a priority. If you add too many break points to your process, you can quickly stack up undone features. The more important negative side effect is that your developers won't develop?competence?and?maturity. Instead, they'll 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 not hard-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 stay constant, you obviously 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 becomes stagnating, 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.

And 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.

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 tasks 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 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 dev is convinced the task needs a review, assign another person to review your changes and ask for feedback. But be confident about the changes you just pushed to staging or production.
• Implement meetings where Code-Reviews happen in a team, not just between two.

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 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.

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.

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 doesn't work without interruptions either. For example, if a developer must consult a colleague during his development process, the colleague needs to switch contexts to help quickly.

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.

Regarding problems in production

A concern with taking Code-Reviews off as a requirement are 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 are?"

"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 really 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 own 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 a very special 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 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 about humans working together. It's about?#mindest ,?#skills , and?#culture ; it's about?responsibility.

Rely on the human in automation.

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 very common, and companies put them in place for their reasons. I understand this; I did the same for our reasons. But 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 which 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, and thus, they are responsible in that very moment for their results, not later!