Pair programming and code review are each practices that improve the quality of software, as well as promote knowledge sharing. When the Agile vs. Lean, XP vs. Scrum, and vi vs. Emacs debates get slow, developers have been known to debate the merits of pair programming vs. code review. Theodore Nguyen-Cao described code reviewers as chickens, and paired programmers as pigs.
The story of the chicken and the pig is often told in agile circles. When it comes to making a breakfast of bacon and eggs, the chicken is involved but the pig is committed. Thus, the term 'pig' has come to be used for those who are fully committed to a given endeavor. The term 'chicken' is used to describe those who are involved, but for whom the stakes are lower.
In code reviews, people sit down to review someone’s code. Everyone has an opinion but not everyone is going to be working with the code on a daily basis. At the time, everyone seems to be involved in the process but there is no vested interest. They are just looking at some code and asking themselves "does this code look good and is it correct?". It’s a very passive standpoint. On the other hand, pair programmers are completely invested (committed?) in the task at hand. They immediately are using the code they are writing together and collaborating their thoughts on design, code layout, etc. Both programmers are taking on an active role and are emotionally invested in the task at hand because they are attacking the same problem together.
Theodore also points out that the feedback loop is much tighter during pair programming than it is during a code review. During pair programming, developers write, inspect, and change the code continuously. A code review, in contrast, involves inspecting the code later, usually when the author thinks it is ready for deployment.
It is generally accepted that the cost of a software bug goes up dramatically, perhaps exponentially, as the time between introduction and correction goes up. By this metric, issues caught during a pair programming session cost far less than those caught during code review. Of course, either of these is much less expensive than letting the bug get released before it is caught. Perhaps it pays to do both.
Do you prefer pair programming, code review, both, or neither? Leave a comment and share your thoughts.