Pull requests somehow became the mainstream technique nowadays. Basically every client which comes to us (we help with legacy Rails apps) has a process based on pull requests. Very often this means they became a mandatory technique. Even worse, in some teams, you can't add any less-related refactoring change as part of a ticket-connected-PR. This, together with the focus on "always-deliver" (read: only work on ticket-connected-PR) leaves no room for the scout rule techniqe.
I don't like that.
I don't like that at all.
Tomek Wróbel at the Arkency blog, summarized the disadvantages of pull requests very well.
Here are some of the points from his list:
- More long living branches, more merge conflicts
- Reviews tend to be superficial
- Merging is blocked by remarks that shouldn’t be blocking
I was very happy to see that in the recent Technology Radar by ThoughtWorks this topic was brought up.
In short, they put it in their "Hold" section. Their meaning of this is "Proceed with caution".
That's my advise too - look at other options available. Even if pairing is not your thing, that are others options too. At Arkency we like the connection of Trunk Based Development, push to master and foreman.
Those maintain the benefits of pull requests (people at the same page), while they shorten the feedback cycle and make the process more productive.
Top comments (0)