Pull request first
After two years of working with pull requests a bit differently from the norm, I now take for granted that most developers submit pull requests only once their work is “ready” for review. Obviously… right? Or… not?
There’s a different approach I’d argue provides more transparency to your team, makes sure everyone is aligned and helps to keep a historical record of what decisions were made when developing a feature. Simply…
Open a pull request before you write code.*
Wait, what? Rather than treating pull requests solely as means for reviewing code, use the pull request as the master of record for the work related to a feature.
This isn’t a new idea — this is an approach our product team at bitHound practiced for nearly 2 years, inspired by GitHub itself (Zach Holman’s talk explains it).
*And yes, technically GitHub requires at least one commit to open a pull request, so you have to write something first.
There are several benefits that we saw from adopting this approach:
Increased transparency
Your Open Pull Requests view on GitHub becomes an instant snapshot of the current state of dev work in your company. Isn’t that what the scrum board is for? Oh, sure it is — and once everyone races to move/write their stickies 30 seconds before standup, you’ll get a similar view (for about 5 minutes).
Specs as you go
By using checkboxes in the pull request description, you can build out the current list of todos, what issues the pull request addresses, and update that as you uncover hidden gotchas during development. Those checkbox counts even bubble up to your pull request list for easy at-a-glance status updates.
This allows other collaborators to know what the progress is on the feature, and let’s them jump in at the appropriate spot. We’d often use these checkboxes to track issues we discovered in development rather than opening new tickets. Or, reference existing issues that will get closed when the pull request gets merged.
Continuous review
Why review when someone has “finished” only to realize they might have taken a wrong turn somewhere early in development? With open pull requests as you work, reviews can be done as the work is done. Sure this isn’t always practical when everyone is super busy, but it works great when you’re bringing a new team member on board, or just working on a doozy of a feature. It’s helped catch problems before they become disasters.
Great for asynchronous/remote work
While our work style was very much centred around in-person discussion, we did have enough occasions where someone was working remotely (home, different country, whatever). I found that this is where the pull request was critical in understanding the state of the project. As long as you kept the pull request current, it didn’t matter if you missed an earlier Slack or office discussion that changed its direction.
What’s the catch?
Is everyone on board? Like any approach to organizing your work, it’s only as good as the effort the team puts into it. So you need to keep each other honest to make sure pull requests are updated in a timely fashion.
Does it scale? I don’t know. Like any methodology, make sure it makes sense for you. When it stops working, tweak something or look for alternatives.
What’s the priority? Unlike a scrum board, there is no clear indication of progress as you can’t reorder open pull requests (without the use of some extensions at least), but you can probably get away with a good labeling/milestone system that helps alleviates this.
Do you do something similar, or find a different approach works better? Let me know in the responses!
Carlos Perez is the co-founder of Purple Sector Strategy. He helps organizations improve their product development processes. See more of his writing at The Pit Wall — A Product Leadership Newsletter.
