Paired Programming - Two people must share the same goal

The technique is simple. Two programmers work on the same machine. One person typing the code (called driver) while the other reviewing the code (called navigator). They keep switching role as frequently as every hour.

What are the benefits you ask?
Well, if more than one developer is aware of the code, the project is less dependent on any single person. Besides, the code is better as two persons have put thoughts about the implementation and reviewed each other’s work. Also, skills and knowledge is transferred between each other without any specific training sessions.

It all sounds good theoretically, but my personal experience has been a little less cushy with implementing this technique in coding. Below is one of the main issues I found in one of the projects that I worked with.

Paired Programming does not work if two people do not share the same goal. John and Tim were paired to code a piece of the software. During the coding, John was also assigned with another important task that only he could perform. After this, I noticed that John was assuming more of a navigator role while Tim is the driver most of the time. Also, Tim noticed a significant decrease in participation from John .He pretty much okayed whatever Tim coded. When I talked to John about it later, he told me that his mind is mostly preoccupied with the other task that he is assigned to. Since the other task is only his responsibility, he can not take any chance for that to fail. He thinks Tim can manage the coding part.
In the above scenario, the whole purpose of paired programming is defeated as it is as good as Tim coding the software alone. The result could be worse as the code will not be reviewed by another developer as the perception is that John has already reviewed it. We ended up in this situation because John and Tim did not share the same goal. Tim’s goal was still coding while John was more focused on the task he was assigned to.