There’s a lot of confusion over pair programming. It’s been widely known for a long time and there are a lot of famous companies such as ThoughtWorks actively using pair programming but on the other side there are still a lot of people not knowing what exactly pair programming is, how it works, what are it’s benefits and downsides. The greatest resource on the matter so far that I’ve read is Stuart Wray’s paper for the January 2010 edition of IEEE Software Magazine entitled “How Pair Programming Really Works“. I really enjoyed reading this article because of it’s scientific approach to the problem.

The main benefits of pair programming are these:

• Communication. While developers explain software problems to each other they often suddenly experience enlightenment and find the solution they were looking for.
• Noticing details. Experiments prove that focused people can miss an elephant in the room. Pair programming partners are usually very helpful to notice various details. For example noticing typos in the code.
• Following code standards. Developers tend to follow best practices more when they work in pairs.
• Expertise judgement. Working with another person in pair is one of the best ways to judge expertise and productivity.

The downside of pair programming is that developers get burnt out. On one hand it forces developers to keep working instead of reading blogs and emails, but after a while developers might get mentally tired and become counter productive. It’s important to allow developers to have some “slack time” if they need to and do some work solo.

ThoughtWorks made a great presentation on how they use pair programming on one of their projects. I highly recommend watching it.

agile, pair-programming, scrum Hide