Have you ever watched Wheel of Fortune with a friend, without the slightest idea what the answer could be, then your friend, thinking out-loud, says one of the words and instantly you can complete the rest of the phrase? Neither of you knew the answer, but as a team you were able to solve the problem neither of you could solve on your own. Given enough time, one of you would likely have figured it out, but by working as a team you arrived at it much quicker. When developing software, the same type of problems can pop-up, and two people can solve them quicker as a team than either could individually… and most often times, far beyond twice as quickly! When situations like these pop-up, it just makes sense from a cost perspective to pair on them so the total amount of time spent on the task is reduced.

The other fundamental justification for pair programming is knowledge transfer. Knowledge transfer is the process where one person shares his wisdom with a peer. This can be done countless was, such as just sitting in a room and talking to a group of other developers, but with pair programming it is baked right it. There are two types of knowledge that can be transferred: business and technical. Transferring business knowledge, such as what must happen in a system for a user to be considered a preferred customer, help to ensure multiple developers in the organization know how the system works and mitigate risk for the company when an employee leaves. Transferring technical knowledge, such as one partner in the pair sharing a keyboard shortcut key with the other, allows developers to become more efficient in how they operate and increase their productivity over the lifetime of the project.

The caveat to pair programming is you shouldn’t over do it. In practice, I’ve found about 20% of the time I pair program, and about 80% I work solo. This varies greatly week to week, and I tend to pair program more (sometimes even 80-100%) earlier in the life-cycle of an application when there are lots of difficult portions to think though and even small design mistakes can be costly down the road. As a project becomes more mature, I usually taper down to closer to a few hours a week, and then there is more emphasis on the knowledge transfer aspect–both what business rules have been developed in parallel that I have not found out about yet as well as what can I be doing to be more efficient while developing.