Code review vs. Pair programming

 Introduction

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.

Conclusion

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.



Comments

Post a Comment

Popular posts from this blog

Validations across micro-services

Image
On my day-job as a consultant for GROUP9  we had an interesting discussion on how to handle validations across micro-services. Let's look at this in the context of a fictionalized example. Example: amazon selling for other companies The case we were discussing was the typical case of referential integrity between two objects. Imagine this: we're Amazon, and being a large e-commerce platform, we want to enable other sellers to use our platform to sell their products, while we handle all the logistics (and of course get a percentage on every sale 😁). To achieve this, we come to an agreement with a seller after some negotiations, e.g. agreeing on the commission percentage we receive on every sale. During these negations, we can add some of the products of that seller to our platform, show them the pricing, additional information etc, so the seller can have an idea what his products would look like when promoted on our platform. Being Amazon, we of course have a micro-services lan...
Read more

Bridging the world of Event Storming and BPMN

Image
In a recent post , Bernd Ruecker made a nice post on a pattern to transform events to commands in MicroServices and DDD. The post discusses the differences between Choreography and Orchestration as two major styles in which various micro-services can be connected and the pros and cons of these styles. Creating business process based systems using DDD is something I've been working on quite a bit. In this post, I would like to take this one step further and also show how the worlds of BPMN and DDD have a very nice fit, even b eyond than just this pattern. To do this, I'm going to make a connec tion between BP MN and a prominent style of analysis in the DDD world - Event Storming by Alberto Brandolini . Also, I'd like to dive into how the strategic design parts of DDD can help us in guiding us where we would like to apply these patterns. The latter will be subject of a later post. Event Storming First things first, lets look at Event Storming and how it is used in DD...
Read more

From Multi-Threaded applications to Multi-Time applications

Image
At the DDD Europe conference.. Recently, I visited the DDD Europe  conference, where Vaughn Vernon held a talk on using Akka an the Actor model to implement applications, based on the principles of Domain Driven Design. This talk, combined with some recent issues I've been facing at my customers site, inspired me to think about the design issues you face when developing multi-time applications. But let's start with what Vernon was talking about at his talk. Vernons talk His main premise: the Actor model is a more simplified model for application development, while at the same time providing a thread-safe environment to fully make use of the ever increasing number of cores processors have. While CPUs don't get any faster, in terms of pure clock speed, they do get more cores, and the we need to adapt our software to make use of these multiple cores. Traditional programming models don't scale nicely because of IO waits causing the software to block and the CPU being ...
Read more