I am a fan of pair programming. Let’s get that out of the way. With that said…
John Sonmez has a nice post on using the practice of pair programming over code reviews if pair programming is an option. There are unfortunately, multiple reasons why adopting pair programming may be challenging and here are a few:
- All the problems he pointed out that impact code reviews
- Existing cultural bias
- Uneven number of programmers
- Distributed development team
Where these challenges exist, code review as a practice may need to be implemented instead. If that’s the case, it’s critical (in my opinion) that code reviews be “online” as much as is possible. It is very common that on teams where the resources are distributed in large organizations that code is submitted for review and the reviewer looks at the code while the coder is sleeping (or generally unavailable). While this “works”, it is in many cases very inefficient (lots of back and forth) and not constructive as it doesn’t provide a forum for discussing and understanding why the code was written the way it was. I believe that the ultimate goal of code reviews is the help coders grow in their coding abilities. If you are doing code reviews with the primary purpose of finding bugs, you may need to revisit your motivation.
If you can pull off pair programming, do it. Otherwise, try to ensure that all code reviews regardless of the location of the participants are conducted with all parties involved.