Code review vs. Pair programming


The other day, I had a discussion with a colleague of mine, about his new role as lead developer in a team. We were talking about the fact that when you are the lead developer of a team, you often bring a certain set of opinions with you on how to do software development within the team you lead. As this was his first assignment as lead developer, we had a discussion on what these opinions were; what will he bring to the team and how will he shape the way they develop their systems?

Soon, we came to the subject on the act of reviewing code, and more specifically, using something like BitBucket code reviewing options to execute a formal review, offline, to approve a pull request from another team member. My colleague indicated he really disliked these formal code reviews, and likes pair programming way better. This sounds quite like an opinion on how to do software development in your team 😅.

However, this got me thinking, as we see in quite a few places at our customers' sites, that formal reviews to approve PRs are mandatory and executed to ensure quality in the system. Is this indeed the best way to organize this, what are drawbacks, and where might we indeed use pair programming instead?

Getting the facts

My first step was to put the question to my colleagues: how do they feel about Pair Programming vs a formal Code Review. The picture below shows the results (sorry for the Dutch), and basically says that a few value Pair programming over Code reviews (option 1), and the rest likes a combination of both (option 4). Nobody liked doing just code reviews (which is what I often see happening, interesting), and nobody liked using Code reviews just for the lead developer (option 3).

To be clear, we discussed the situation where a code review is done AFTER doing pair programming, but only with the goal to record the fact that someone else watched this code being crafted. I.e. no actual code review was done afterwards. We counted this as "prefer pairing".

So digging into this further, why a combination of both, and more importantly which type to use when? And the answer is of course.....

It depends!

As always, this answer can be translated as "It Depends", the main mantra of Consultants around the globe. Given we pride ourselves on providing a bit more info than "It Depends", we dug a bit deeper. When would you use Code reviews over Pair programming, or vice versa. Basically, the end result was: 

You should prefer Pair Programming over Code Reviews in all but the most simple cases. If you have some really easy use cases you need to implement, then a code review afterwards is probably easier. This can also work if you are able to split the work you had into multiple smaller parts (little tasks) where each task is really simple, and reviews can be performed fast.

The main question one might ask oneself, is if you are doing a lot of simple use cases quite often, aren't you doing it wrong? Really sounds like you are violating the DRY principle in these cases, but that may be subject of another blog post.

The main disadvantages of Code review were:

  • Lack of any understanding what the author is trying to achieve: you just have to guess based on the code itself what the author was thinking. And of course, good code should be self-explanatory, but knowing what the author was trying the achieve and why is still hard to fantom.
  • Basically it's just very boring to do. Hardly anyone likes code reviews, which causes people to start losing focus, resulting in less well executed code reviews, and a decline in overall quality
  • Personally, doing a code review I feel this attributes to an atmosphere of not trusting people, instead of cooperating to build something together. The effect is not really large, so not a big issue, but I still wanted to mention it.
  • It leads to more work: when you are able to discuss the code review while it's being made, and are able to steer away from wrong choices because of that, it actually saves you a lot of work which is done in polishing the code, finishing all unit tests etc. Only to figure out in the end we want to rewrite the whole code, or use a whole different solution which negates all that work that has already been done. I experienced this first hand when I was involved in a code review, only to come to the conclusion after the fact that the whole plan people had was bogus to begin with and wouldn't work anyway. All that work could have been saved.


In the end, this is an interesting result, as we often still see a lot of cases where Code reviews are thought of to be mandatory, and Pair programming is viewed upon as a waste of time. Sounds to me like we still have work in pushing for more pair programming, and less boring work. 

In that sense, the discussion I had was a good trigger to reevaluate my own belief system and start focussing again on promoting pair programming, convincing project management on the merits of this approach over the stuff that nobody likes to do anyway. The last part of the disadvantages is most important in that sense: when done right, pair programming will probably actually save you time when developing software in the end.


Popular posts from this blog

How Lombok can throw you off guard - Java Compiler fun

Bridging the world of Event Storming and BPMN

Validations across micro-services