PRs & Code reviews are a blocker and bottle-neck for value generation. Allow me to explain.
A Pull-request was a feature created to allow maintainers of an open source project to receive changes from unknown contributors. It solves a trust problem, allowing the maintainer to review code before rejecting or accepting changes.
Developers working together as part of a team don't have trust issues. Otherwise, it is a different problem in which PRs are not the solution. At best, the issues of a team are about quality and norms.
Automating testing and practices like TDD, CI, and CD can solve quality problems. Automated tests create faster feedback loops when compared to a PR waiting for review and the usual back & forth with comments.
Testing Driven Development helps developers to design their code better and enable testability. Tests are created to support the acceptance criteria in the stories. When they all pass, developers are free to merge the code and move to the next story.
Continuous Integration reduces the chances of merge conflicts. It supports the idea that any code in the main branch is working software ready to ship to production. Pipelines produce feedback and help to avoid regressions.
Continuous Delivery accelerates teams by avoiding branch strategies. Everything is merged into the main branch and continuos tested. Code is deployed into production often, and feature flags can be used to allow for tests in production or canary releases
Pair Programming or Mob Programming eliminates the need for code reviews. Code is reviewed as it is produced. Disagreements can be solved on the spot instead of async through comments. Knowledge is shared, avoiding silos.
Norms can be enforced with code static analysis tools as part of the pipeline and pre-commit hooks. Quality gates can be added to implement minimum thresholds. Developers can focus on value generation rather than reviewing code that is faulty in style but functionally correct
For regulated markets, compliance and regulations can be satisfied without code reviews in most cases with modern Quality practices.
Unless you are developing an open source project, you should seek to stop doing PRs & Code Reviews. It will accelerate time-to-market and help to improve the product further with more frequent customer feedback.
Top comments (7)
Nice idea!
Willian, I would have agreed with you 100% about 3 years ago. What's changed for me since then is that I've been working with people that use PRs as an opportunity to peek at something they did not participate in and catch some fat-finger mistakes that are obvious to them, but perhaps not obvious to everyone else. The PR is not the quality guarantee -- it is just an additional proof-reading.
And code reviews, when done properly, are just a show-and-tell opportunity for a Q&A PR experience.
I am with you that using PRs and code reviews as a substitute for other good practices is a poor strategy. (Speed of trust is fastest way to quality completion -- here are my thoughts on that 8 principles of effective collaboration)
Thanks for your comment Frank and nice article!
Code reviews can be done without PRs, as a team exercise. Pair Programming combined with TDD is enough to improve confidence to ship - at least that is my experience working with teams, even on high regulated markets where the requirements for evidence is higher.
Well fine that automated tests eleminate quality issues. And what is when there is no test added that comes within a new features because there were no pr that claims about missing tests. PR is not about trust issue when I make a pr I am also more confident if at least one additional programmer who knows the business logic checks my code.
Thanks for your comment Kyle; to clarify:
PR is a solution for a trust issue in the context of an open source project for the role of a maintainer. I even said explicitly that "Developers working together as part of a team don't have trust issues".
Following the principles I've listed, if you have TDD in place, the scenario where you don't have tests for new features does not exist. Also, working in pairs, gives the confidence that a second pair of eyes see your code before you merge.
How often is / should pair programming happen?
When working on user stories, you should work always in pairs - with proper pair rotation- or do mob programming. PoCs and spikes can be done individually, but the code produced should not be used for user stories but to inform team decisions.