Pair Programming

Pair Programming is not always considered an absolute requirement of an Agile project, but is closely associated with Agile, especially the XP methodology. The standard approach is to assign each developer a pair for an iteration, then assign stories to the pair. The pair sits side-by-side throughout the iteration as they architect each solution, code, create unit tests, and promote. There are some pros and cons to this approach.

Pros

The advantages of pair programming include:

• Better design – When two people plan together, the added scrutiny can result in a more robust design that can cut down on the need for refactors due to poor design.
• Better focus – When developers are working in pairs, they may be more likely to focus on the task at hand rather than surfing the net, chatting online with their 52 buddies, etc.
• Continuous code review – While one person is coding, the other is basically performing a real-time code review, pointing out potential issues. This can result in better quality code and less bugs.
• Knowledge transfer – Whether it is a junior developer teamed with a senior developer, or a new team member teamed with a seasoned team member, pair programming can greatly assist in knowledge transfer. This can include knowledge about the technology, the business, the project process, etc.

Cons

The downsides of pair programming include:

• Redundancy – Some people argue that some development tasks such as unit tests do not benefit from pair programming. In general, some argue that the more senior the developers are, the less value the pairing provides.
• Developer resistance – Some developers and some entire teams resist pair programming. Reasons include feeling like they don’t need a babysitter, dislike having someone constantly looking over their shoulder, an aversion to a particular individual as a pair for a few weeks straight, etc.
• Inconclusive benefits – An oft-quoted study indicates that pair programmers are happier, and a 15% increase in quality makes up for 15% slower delivery. However, as some critics have pointed out, the research is suspect and inconclusive.

Recommendations

There are a million ways to implement pair programming, from a limited basis to full-time. Every team is different. Some love pairing, some hate it, some find value in pairing for one exercise but not another. Give it a try and tweak until you have the optimal use of pair programming for your project and team.

My personal preference is to pair full-time only when you have lots of junior developers, or if you wish to help a new team member come up to speed. For teams consisting mostly of more senior developers, I follow these guidelines:

• Assign stories to individuals – Assign stories to developers individually.
• Design as a pair – Once story assignments are made, developers should review their stories and come up with a plan of attack. They should then meet with their pair to discuss their respective plans, providing feedback to ensure a sound plan.
• Develop individually – Once they have an agreed-upon design for their stories, each developer can develop on their own.
• Use pair as first line of support – As questions arise, roadblocks loom, or as your design requires reevaluation, discuss options with your pair.
• Perform code review as a pair – Prior to promotion of the code, have your pair perform a code review.

This approach is best suited for a reasonably senior team and does not provide the continuous code review or enforce focus. However, I have found that it provides many of the benefits of pair programming while greatly reducing redundancy, thereby enabling the development team to enjoy the best of individual and pair programming and thereby obtain optimal performance.