A pair programming guide
This section is dedicated to the practice of building software in pairs. This practice has been popularized through the umbrella of eXtreme Programming gaining attention from practitioners due to its positive effects on code quality and knowledge sharing. However, the concept of pair programming was shown in the 50’s [1][2]. Catalino suggests that pair programming, has been around before the agile movement [3].
Since 1999, http://www.extremeprogramming.org has been a place that gathers resources about the practice and theory of eXtreme Programming, that teams can use and adopt.
In the world of software development, pair programming has emerged as a valuable technique for improving code quality and fostering collaboration among developers. However, like many agile practices, its implementation can be challenging. This is where this page comes into play. This page presents a set of materials that offers a guide from start to finish on adoption of pair programming taking into account professional teams working for organizations (of any size).
Through the materials, resources for further investigation are provided, quiz are used to test the knowledge and understanding of readers and real cases are shared from my personal experience practicing pair programming for more than 4 years as a full time practice.
1. Introduction to pair programming
2. Benefits
Code Quality
Pair programming tends to enhance code quality since two developers work together to review and refactor code in real-time. Collaboration: It fosters closer collaboration between team members, leading to better understanding of the project and more creative solutions. Challenges:
Implementation in Large Teams
In larger teams or with rigid organizational structures, implementing pair programming can be more complex. Resistance to change and lack of understanding can make adoption difficult.
Problem-Solving
Pair programming facilitates solving complex problems by having two minds working on the same code. Learning: It is an excellent opportunity for mutual learning and knowledge transfer among developers.
Challenges
Shifting a team’s working style can be challenging, especially if the company’s culture is not open to new practices.
- Convincing the Team: Persuading all team members to adopt pair programming can be a daunting task. Resistance to change and differing working styles are common obstacles.
- Bureaucratic Environments: In very large and bureaucratic companies, implementing pair programming can face more barriers due to rigid structures and a lack of flexibility.
2. Empirical evidences
-
The Social Dynamics of Pair Programming
- 4 months of study with two teams
- team a
- formed in 2004
- familiar with the code base
- pair was negotiated daily
- team b
- formed in 2002
- 9 programmers
- Teams A and B were not knowledgeable about their tasks
- difficult tasks were done via spike
- results:
- driver/navigator myth: no consistent division, the pair often switches between both at different points in time. The one driving also brings strategic thinking into the mix.
- shared context: The pair after a bit of discussion and agreement on the path forward were in sync and one completed the other line of thought.
- keyboard control: the programmer that controlled machine input had a distinct advantage concerning decision-making.
- discussion:
- programmers were more engaged when they were controlling the keyboard, however, each person of the pair had different configurations that became a barrier for switching keyboards more frequently.
- Expertise emerges as a particularly important factor influencing pair interactions, a finding which affirms both the arguments made by Williams and Kessler [6] and informal reports that individuals dislike pairing with someone with lower expertise [12, 17]. Rhetorically, when the difference in expertise is large, the programmer with less expertise has difficulty assessing the technical arguments put forth by the “expert”
- In our observations, pairing less knowledgeable programmers with more knowledgeable programmers did seem to be effective when the less knowledgeable programmer was new to the team and code base.
- Academia based
- Social Behaviors on XP and non-XP Teams: A Comparative Study
- The Costs and Benefits of Pair Programming
-
Chapter 2: Processes – Software Engineering: A Modern Approach
- there is a part of the text the Marco shares a study by Microsoft with research and empirical data baking the practice
- Pair programming - Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement as a counterpoint, this study shows that pair programming raked low
- Industry related
- Youtube playlist by Matheus Marabesi
- What if we rotate pairs every day? by Gabriel Robaina and Kieran Murphy at martinfowler.com
- Global Day of Coderetreat 2022 - London Retrospective
- Pair Programming Simplified
- Global Day Coderetreat 2021 at Codurance Spain
- Should I use Pair Programming?
- Remote Pairing a True Story
- Joining Codurance - the pair programming interview experience
- Finding the biting point with pair programming
- Rethinking Pair Programming
- In spanish
Pair programming anti-patterns
References
- [2]N. S. Birgitta Böckeler, “On Pair Programming.” 15-Jan-2020 [Online]. Available at: https://martinfowler.com/articles/on-pair-programming.html. [Accessed: 05-Apr-2025]
- [3]“What is Pair Programming?” May-2023 [Online]. Available at: https://www.drovio.com/blog/what-is-pair-programming/. [Accessed: 05-Apr-2025]