No, you don't need pull requests
You need more collaboration in your team and more confidence in your teammates. The combo of trunk based development with pair programming will show you how.
In software industry, there are things we've been doing for so long that we forget why we are doing them that way. They are so ingrained in our ways of working that it is difficult to think about other options. Or we can even see other options, but we're afraid they wouldn't work in our team, 'cuz they only fit that cool small company that uses Extreme Programming.
After moving from a feature branch approach to trunk based development (a.k.a. pushing directly to the main branch), I realised that using pull requests to review code is one of those things that I didn't know why I was doing. It had to be done, everyone was doing it!
This change would've fit my life as a developer years ago, so I want to spread the word about using trunk based development plus pair programming instead of feature branch development with pull requests.
There are two things humans really hate. One: things remaining the same. Two: change. — Kevlin Henney
Code Review
Using pull requests is just one of the techniques to review code. Code review is still important for all the obvious reasons. The alternative is to do it on-demand, as we go, in pair programming sessions.
Pair Programming
Instead of one developer writing code alone, then opening a pull request that needs others' approvals (how many are needed?! who decides this?!), we have two developers working together all the time, switching the driver from time to time.
All the time?
Yes. In this model there's no you, your headphones, your music, your coffee mug and the code. This is about collaboration. We do constant small breaks to rest and to keep the pair's quality up.
Every two days we rotate pairs and we track the pairing history from the last two weeks to help us decide the next pair and to guarantee we are varying enough. Rotation frequency is just an implementation detail, but the more frequent it might be more difficult to coordinate. Once per week might be a good start, and then make it shorter.
We have a default rule that helps the rotation: the person that has been working the longest in the user story leaves the pair. This means that every few days a developer changes context and works in a different story.
Who's the driver?
It's the person driving the keyboard and editing the code. The other person is the navigator and is reviewing the code meanwhile. Both roles are responsible for writing and reviewing the code, though. So we switch roles often enough to achieve this balance and to avoid overwhelming the driver (usually it's more exhaustive).
But… I already do pair programming!
Well, be careful. For this model to work, pair programming must be constant and organized. If you have to convince people to pair and you do it sometimes "when you can", this is not enough to do trunk based development.
We have to make sure pairing is the only way to deliver software in our team. It's part of our daily routine. When we get to this point we will organically see that pull requests have become unnecessary.
Benefits
Changing a team's way of working is not easy, although adopting this model is simpler than you imagine. In case y̶o̶u̶ ̶a̶r̶e̶ ̶s̶t̶i̶l̶l̶ ̶r̶e̶a̶d̶i̶n̶g̶ you got curious about it, here are some benefits in using the combo of trunk based development + pair programming.
Faster!
No more messages begging your teammates to review your pull requests, no more waiting for pull requests to be approved, no more infinite comments threads. Everything is said and done face to face (or cam to cam) and the code is shipped much faster, which sounds pleasant even if you're not a product manager!
Teammates confidence
It doesn't matter who you are pairing with and their seniority level: both of you are just enough to ensure that the code can be shipped. No superhero (or super-approvals) and no one becomes a bottleneck. Mutual trust is enforced.
📝 Pull Requests make sense in low-trust environments, such as Open Source projects, because we don't know the other person and pairing is completely unfeasible.
Knowledge silos
Pair programming combined with frequent rotations makes different developers act in one user story lifecycle, which spreads context and decreases knowledge silos. In addition, constant communication makes us rely less in assumptions.
Full-stack'em
Depending on the type of the work to be done, if it's more front-end, if it's related to metrics or if it's a technical investigation, we'll have to get out of the comfort zone and deal with things we're not experts in.
⚠️ Dividing pairs in "front-enders" and "back-enders" is highly discouraged because it restricts the rotation and the benefits this model provides.
Quality
Because code review is done "on the fly" and in collaboration, the chance of finding an issue, identifying improvements and acting upon them is much higher in pair programming. No more this:
Incremental changes
Keeping changes small and pushing them incrementally is important because both combined reduce risk. In trunk based development there's no space to fear deployments: "If it hurts, do it more often", that's the mantra!
Also, since we're all using the main branch, rebasing and reverting must be easy. Functionality must be split because pairs will change and different people will contribute to it until it's done.
📝 Back when I was using pull requests, I was the b̶o̶r̶i̶n̶g̶ one claiming for really small PRs. I guess they got so small that they disappeared.
📝 Using (some) code comments can help us keeping commits small and cohesive.
Sustainable pace
First we code it all and then we review it all. First this, then that. Reminds you of something? Yes, the waterfall approach! Whereas trunk based development with continuous pair programming aims for collaboration and matches perfectly the first rule of the Agile manifesto:
"Individuals and interactions over processes and tools." — Manifesto for Agile Software Development
Beating enemies
"All this looks great, but it is easier said than done". Besides the list of benefits above, let’s cover some concerns that might discourage you from trying to move to this new way of working.
Buying other people
This far, I hope you already have enough arguments to do that. Techies will probably be your allies with experimenting this. Non-techies don't need to influence this decision, as long as the team keeps showing working software every iteration.
Ask the technical leadership for a vote of confidence and try it! If you’re in a high-trust and Agile environment, it should be perfectly OK to experiment new things and iterate over them (even if it’s just to prove myself wrong and to write in favour of feature branches with pull requests).
Test suite confidence
This is not a requirement exclusive to trunk based development! But in this case, the test suite must give you enough confidence to be pushing code to the main branch, which will trigger new deploys (CI/CD is assumed mandatory).
The more high-level tests that are focused on users' behaviour the better. An ice-cream sandwich test suite is preferred than the outdated test pyramid. Do not rely on manual testing, because it won't be enough to move to trunk-based.
📝 Using Test-Driven Development is highly encouraged and fits perfectly.
Pre-production validation
If everything that we push will automatically trigger a new deploy to production, can't we validate deliveries in a pre-production environment (a.k.a. staging)? Yes, we can!
Almost every feature is rolled out using feature flags. That way, we can put things live safely, making them available for internal users first and making it possible to do QA.
📝 Flagging means one different and (probably) temporary way to fulfil a use case. Avoiding feature flags' ifs all over the code is highly encouraged.
Remote teams
After the COVID-19 pandemic hit, all companies were forced to become remote-friendly (at least for some time). And since this model reinforces collaboration and pair programming happens almost 100% of the time, you might be thinking this is not a good idea for remote teams. Lie!
I️n general it works really well even in teams with (not so) different timezones, with flexible hours or different working hours per day. It might happen that your pair will leave earlier, but you can always join another pair or work in something else for a couple of hours.
📝 Tools that will help you pairing remotely: Pop, Drovio, Tuple.
⚠️ Teams with huge timezone differences will struggle, though.
Greenfield vs. Legacy
It doesn't matter if you're starting off a brand new project or if it's a legacy one. It also doesn't matter if you're using microservices or if it's a modularised monolith. However, being in a greenfield project with a small team would be even simpler to go for it!
Conclusion
Continuous Improvement is not only applicable in code: questioning the ways of working of your team will definitely show you new possibilities that might fit you even better!
"Continuous Improvement seeks to improve every process in your company by focusing on enhancing the activities that generate the most value for your customer while removing as many waste activities as possible."
It is true that using trunk based development requires team's maturity, but my last call is to start trying it with what you have now and you'll be forced to bring in this maturity. Extreme Programming rules can help you with this further step.
If you’re using feature branches in a way that every merged pull request triggers a new deployment, moving to trunk based will not increase risks of introducing bugs. In both cases you rely on the same test suite, you use the same (good) practices to write code, but trunk based development will give you all the benefits mentioned above.
Ready to try it?