Pair programming is an agile software development technique which involves two developers, two monitors, two keyboards, and two mice, but only one computer. A pair consists of the driver, who controls the keyboard and mouse, and writes the code, and the navigator, who guides the driver, reviews the code, focuses on the strategy, and the direction of the code. While pair programming increases the man-hours required to deliver code compared to programmers working individually, it has many benefits.

Benefits

• Collaborative culture.
• Boosts software product quality.
• Improves long-term codebase maintenance.

Intangible benefits

• The courtesy of rejecting phone calls or other distractions while pairing.
• Taking fewer breaks at agreed-upon intervals.
• Shared breaks to return phone calls, but returning quickly since someone is waiting.
• One may have more focus and help drive or awaken the other if they lose focus.
• One may have knowledge of a topic or technique the other does not.

Design quality

A system with two programmers possesses greater potential for the generation of more diverse solutions to problems for three reasons:

1. The programmers bring different prior experiences to the task
2. They may access information relevant to the task in different ways
3. They stand in different relationships to the problem by the virtue of their functional roles.

In an attempt to share goals and plans, the programmers must overtly negotiate a shared course of action when a conflict arises between them. In doing so, they consider a larger number of ways of solving the problem than a single programmer alone might do. This significantly improves the design quality of the program as it reduces the chances of selecting a poor method. [ 8 ]

Quality of code and projects improve

• Two pairs of eyes are better than one. Continuous collaboration and code review helps pairs spot and resolve issues early, leading to fewer bugs.
• Pairing will result in 15% fewer defects than solo programming. [ 1 ] Higher quality code and faster development.

Increased productivity

• Communication speeds up development.
• Division of labor: pairs accomplish more and can plan ahead.
• Pairs are accountable and stay focused.

A study shows positive results

• Pairing engineers increases efficiency by 14% [ 2 ]
• Pair produced work is equal to that of 2.27 programmers. [ 2 ]
• A study by Sabre Airlines showed productivity increased 50% compared to a previous release using solo programming. [ 3 ]

Scalability

• Pairing enables exponential project growth. A pair can split-up and work alongside 2 new developers, over and over again.

Knowledge transfer

• In a 2 hour pairing session, knowledge transfer happens 35% of the time. [ 4 ]
• Pairs share programming tools, coding languages and techniques, and agile processes.

Code ownership & maintenance

• Through pair rotation, multiple engineers learn the codebase. This enables project maintenance and longevity.
• 60% pair-programmed code for 2 mobile apps were more maintainable than solo-programmed code. [ 5 ]
• 82% of developers found paired software was clear, maintainable, and extensible. [ 6 ]

Job satisfaction

• 80% - 95% of pair programmers feel more confident in their solutions when they pair programmed.  [ 6 ][ 9 ]
• 29 participants in a study noticed an increase in team morale. [ 6 ]
• 96% of pair programmers stated that they enjoyed their work more than when they programmed alone. [ 9 ]

Results from a study with 108 developers

• Pairs see improvements in their interpersonal and communication skills. [ 7 ]
• Shared responsibility reduces stress and pressure, boosting confidence. [ 7 ]
• The study revealed that pair programmers have higher job satisfaction than solo programmers.

Do's and Don'ts of pair programming

Do

• Focus on the task
• Switch-roles in a session to gain a new perspective
• Be patient when working with a new pair
• Be enthusiastic and contribute
• Take breaks
• Regularly communicate issues and successes

Don't

• Be egotistical
• Get distracted
• Don't work alone
• Rotate too often
• Pair with the same people time after time

Sources

1. Carolina Alves de Lima Salge & Nicholas Berente. (March 10, 2016). Pair Programming vs. Solo Programming: What do we know after 15 years of research.

2. R. W. Jensen. (2003). “A Pair Programming Experience,” CrossTalk, The Journal of Defense Software Engineering, vol. 16, pp. 22 - 24.

3. Lucas Layman, Laurie Williams & Lynn Cunningham. (2004). Exploring Extreme Programming in Context: An Industrial Case Study.

4. Franz Zieris & Lutz Prechelt. (2014). On knowledge transfer skill in Pair Programming.

5. Hanna Hulkko & Pekka Abrahamsson. (2005). A Multiple Case Study on the Impact of Pair Programming on Product Quality. http://agile.vtt.fi/docs/publications/2005/2005_multiple_case_study_pair_programming.pdf

6. Mikael Lindvall, Dirk Muthig, Aldo Dagnino, Christina Wallin, Michael Stupperich, David Kiefer, John May & Tuomo Kähkönen. (2004). Agile Software Development in large organizations.

7. Giancarlo Succi, Michele Marchesi, Witold Pedrycz and Laurie Williams, (2002). “Preliminary Analysis of the Effects of Pair Programming on Job Satisfaction”, Proceedings of the 3d International Conference on Extreme Programming and Agile Processes (XP 2002), University of Cagliary, Italy 2002, pp. 212-215.

8. Flor, Nick V.; Hutchins, Edwin L. (1991). "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance". In Koenemann-Belliveau, Jürgen; Moher, Thomas G.; Robertson, Scott P. (eds.). Empirical Studies of Programmers: Fourth Workshop. Ablex. pp. 36–64. ISBN ISBN 978-0-89391-856-9.

9. Williams, Laurie; Kessler, Robert R.; Cunningham, Ward; Jeffries, Ron (2000). "Strengthening the case for pair programming" (PDF). IEEE Software. 17 (4): 19–25. CiteSeerX 17 (4): 19–25. CiteSeerX 10.1.1.33.5248. doi:10.1109/52.854064.

More Information

• Alistair Cockurn & Laurie Williams. (2001). The Cost and Benefits of Pair Programming

• Jeff Langr. (January 8, 2007). Pair Programming Dos and Don'ts. http://www.developer.com/lang/article.php/3652636/Pair-Programming-Dos-and-Donts.htm

• Laura Williams, Robert R. Kessler, Ward Cunningham & Ron Jeffries (2000). Strengthening the case for pair-programming http://www.cs.utah.edu/~lwilliam/Papers/ieeeSoftware.PDF

• Witold Pedrycza, Barbara Russob & Giancarlo Succi. (2011). A model of job satisfaction for collaborative development processes.