Code review vs. Pair programming
Getting the facts
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.