Pull Requests encourage critique, even in small teams

A member of our team recently suggested that we use pull requests in our development workflow.  Many points were made for and against in our debate.  After only a short time of adopting this change, the major benefit I have seen is the increased critique of the team's output.

The debate

The decision to use pull requests was certainly not a given and gave rise to an interesting debate.  Many arguments were made for and against which I've tried to summarise below.

For pull requests

  • Increased knowledge sharing - Non reviewers can view pull requests just as easily.
  • Simpler commit messages - Each pull request is (hopefully) created "with the reviewer in mind" .
  • Provides a forum for commenting on work.
  • Increase in code quality

Against pull requests

"It's too much process and will slow things down"

As a small team I think we take pride in our lightweight process of pair programming and informal ad-hoc code reviews.  Adding extra checks and process to the deployment pipeline feels almost like a step backwards as we try to cut back on red-tape.  

Counter argument: No other rule would be introduced alongside using pull requests.  This means anyone in the team (except the author of the change) can accept anyone else's request.  Where possible, we'd aim for one pull request per user story.  Perhaps this argument/concern was a fear of pull requests just being the start of a new heavy weight approval process?

"Pull requests lead to bigger and later code merges than the smaller earlier merges of committing straight to master"  

Given that a pull request should encapsulate all changes for a single user-story (or task), this is somewhat inevitable. 

Counter argument: This issue is mitigated by staying focused on the task/story in hand.  If the developer(s) happened to get sidetracked and begin re-factoring, this should be split into a separate pull request.  If a pull request does encapsulate a single user story, task or refactor it becomes easier to review and understand changes made to the code base.

"We pair program... we don't need a extra reviewer"

Counter argument: A fresh pair of eyes can spot things that even a diligent pair might miss.

Benefits I have seen since adopting pull requests

They encourage critique in a way I didn't expect

Pull requests seem to frame a change as a question and not a statement.  My impression is that:

  • Committing to master states: "I am done with this".
  • Submitting a pull request asks: "What do you think?"

It is so much easier to make a comment or suggestion when someone asks for your opinion than when you initiate the dialogue yourself.  The more that comments and suggestion are encouraged, the better the team's output will get.


Popular posts from this blog

Lessons learned from a connection leak in production

How to connect your docker container to a service on the parent host

Client Side vs Server Side Session