With the rise in popularity of agile software methodologies, the practice of formal code reviews has been often put against pair programming. There are proponents for both and some even recommend practicing both.

As time goes on, I’ve been able to do a little bit of both and I’ve developed a strong preference for pair programming over code reviews.

With code reviews, you get one or more other persons to review the code you just wrote and feel ready is to be checked in, deployed, or whatever the next step is. These reviews can be very formal or just as simple as a line-by-line walk through the code. The goal is to find any bugs or fixes before the code gets to the next step. This is very analogous to the writer/editor/publisher workflow (kind of like this blog entry). Writer writes the article, editor proofreads, and the article gets published. Programmer writes the code, other developers review the code, and the code gets deployed. It almost seems like the idea of code reviews came out of software methodologies like the Waterfall model. Everything is very sequential and done in distinct stages.

In pair programming, the focus is on developing “good” code the first time around. We do this by having more than one pair of eyes on the working code as it is being written. One person is the “driver” who is writing the code and the other is the guide or observer who is verifying the code being written and thinking of potential improvements. The developers switch roles whenever it makes sense which in many cases causes one developer to immediate use or have to work with the code that was written by their partner. It places emphasis on the idea that two heads are better than one.

Two things come to my mind when I think about pair programming and code reviews. First, code reviews seem to be a just-in-the-nick-of-time fix for finding bugs in code before it goes out the door. The initial development effort as already been completed and now we are evaluating the work. And realistic, this is code we’re looking at. Everyone has their opinion as how things should be structured, design philosophies, coding styles, etc. Many times code review sessions end up focusing on higher level concepts like those previously listed and not on the code itself. These kind of debates are related to decisions that should have been made prior to writing this code. Why are we asking ourselves why we did this this way now after we’ve already spent time and effort to write code for it? And the people part of the code review are not neccessarily the people that will be working with that piece of code.

That brings me to my second thought which is this is all reminiscent of Scrum pigs and chickens.

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 collobarating 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.

Most of the cons of pair programming can be attributed to developer social/ego issues. And they are not specific to pair programming. Going down the list of drawbacks listed on Wikipedia:

• Developer egos: Experienced developers may find it tedious to tutor a less experienced developer in a paired environment.
• Developer intimidation: A less experienced developer may feel intimidated pairing with a more experienced developer which may result in less participation.
• Developer work preference: Some engineers prefer to work alone, and may find the paired environment cumbersome.
• Tutoring cost: Experienced developers working alone may be capable of producing code that is clean and accurate at the outset, and the additional theoretical gain from pairing might not be worth the cost of an additional developer. This is especially true when producing more trivial parts of the system.
• Potential conflict: Differences in coding style may result in conflict, and personality conflicts can result in one or both developers feeling awkward or uncomfortable.
• Chat sessions: Sometimes employees might talk together too much, straying excessively into off-topic subjects, such as major news events, personal problems, etc.
• Annoying personal habits: Sometimes people can find each other much more annoying when working up close than at separate workstations.

Developer egos, intimidation, work preference, and tutoring costs are things that should be checked at the door. As an experience developer, you should look for opportunities to help your fellow developers to learn and improve their skills. As a more junior developer, the opportunity to take chances and try to prove yourself is one of the best ways to learn and develop better skills. I don’t know about other people but collaborative work environments seem to be a plus. Being able to discuss your ideas openly is one of the best ways to make what you’re building better than it is. As for potential conflicts, chat sessions, and annoying personal habits, these have more to do with personalities and mannerism in the work place. All of this can happen in code reviews as well but the point is being self-aware and respectful of your coworkers is just as important as writing awesome code.

While I’m not against code reviews, I feel that pair programming is better suited to improve both code and team quality.