… something on Pull Requests vs Trunk Based Development
I’m a strong believer in Trunk Based Development (TBD). If you’re not sure what that is, there’s a very good resource explsining it here: https://trunkbaseddevelopment.com/ (It does what is says on the tin).
Since joining Redgate six months ago I’ve watched in fascination at how well ingrained the existing Pull Request (PR) system is, as well as the benefits of having every commit reviewed; and the push back against suggestions of not doing this — and it does feel heretical suggesting it.
The problem with using PRs is the lag introduced into the system. A developer finishes some work and then has to wait. And sometimes they have to wait and wait and wait. All for someone else to review their changes. And if you want to make changes on top of changes, you end up in some sort of fragile Inception-type scenario, building castles on clouds. All of this can cause the levels of Work In Progress to balloon.
As a devotee of Lean methodologies, bottlenecks, lead-times and constraints like this in a system are what I try to root out. Get rid of. Vanquish.
On the flip side, I can see the juicy goodness of constant feedback on code. Though I have also used the phrase “The tyranny of the code review” to describe the block to improvements by refactoring with the “That’s not on the card, that’s not getting through” attitude.
At Agile Cambridge 2018, Seb Rose was arguing that the *primary* purpose of a code review should be to check code readability in the long run. The other functions (correct functionality, intent check, formatting etc, hell — even talking to each other) having been carried out by analysis, pairing and automated checks (etc).
This gave me food for thought at the time, and I’ve been wrestling with it ever since.
Whilst we had Thoughtworks in our office for a few weeks, I hosted a well attended Goldfish Bowl event to get an broader industry-wide view on the topic, and I’m hoping that will be a separate post at some point [I will update this when that happens].
As part of our investigation into the Accelerate book, Redgate have been discussing how to up our game, and this is going to be a hot area for debate.
Ultimately, to be a High-Performer, which we want to be, one of the four metrics described in the book requires the ability to get a change through from a developer’s machine to released in under an hour (on average). The brutal truth is that a process involving a Code Review won’t allow us to do that unless by exception, and certainly not on average. And no, we don’t want to game it.