Pair Programming is Nuanced

For anyone who follows me on Twitter or even here on my blog, you know my PhD topic is pair programming. Which is why this tweet got my attention. I figured it contains some commonly held beliefs so I thought I'd share why having this conversation is difficult and why it's not an all or nothing choice.

Let's start with...

The Definition

Pair programming is where two programmers work together at a single computer. One writes code while the other observes and offers suggestions.

The definitions of pair programming differ slightly especially in what they define as the objective. For example, different definitions set the objective to be to develop software collaboratively (Hanks, 2008), to work on a programming task (Sun et al, 2019), or to write production code (Socha & Sutanto, 2015). Some definitions explicitly state the pair must share one workstation (Smith et al., 2018) and others generally describe working closely together (Plonka et al., 2015).   

Distributed pair programming (DPP) extends the practice of pair programming by allowing the partners to pair while geographically separated (Hanks, 2008). As with collocated pair programming, definitions of DPP can differ. Tsompanoudi et al. (2016) define DPP as developing software remotely using specialized infrastructure. While Baheti et al. (2002) very specifically describe DPP as sharing desktops with one member of the pair having read-only access while the other actually edits code and communication occurs over microphone or instant message.

Two programmers using the same computer while one writes code and the other offers suggetions is both incredibly specific and overly broad in all the most problematic ways. First, the definition is limiting in what each member of the dyad can do. It sounds like a strict application of the driver-navigator paradigm which is one that I'm not fond of for pedagogical reasons and part of what led me to my PhD program. Second, the overly broad side, there's no mention of collaboration, problem solving, or any objective other than writing code. Personally, the defnition I ascribe to is a team of two developers working collaboratively to develop software.

The Economics

One of the first places the discussion for pair programming goes is to the economic benefits. Are two heads really financially a sound decision? Sun et al (2019) do a fantastic purely mathematical breakdown of the economics of pair programming based on defect rate and rework speed. Their conclusion was that it IS true that pair programming is not better than solo programming in ALL situations from a purely economic perspective. They point out that in order to make economic sense, pairs have to be 23% faster and make 25% fewer mistakes (Sun et al, 2019). Not the 2x output mentioned by the OP, but also not an insignificant difference. Sun et al (2019) also point out that what impacts the effectiveness of a pairing is pair composition which in and of itself has many sub-factors like gender, expertise, power dynamics, personal relatedness, and sometimes just if you're having a good day or not. They also mention the project characteristics and organizational culture as impact factors. Economics, however, is one specific outcome and in this case in one very narrow view - if Bob and I code faster with less mistakes it will be worth the money to have 2 salaries working on the same problem. The outcomes for pair programming are much more complex than that though.

Goals for a pair programming session can fit into three buckets. The first is to develop the software. Some definitions refer to it as solving a problem (Smith et al., 2018; Plonka et al., 2015). Sun et al. (2019) calls it a programming task. Other research refers to it as developing software (Hanks, 2008; Rasmusson, 2002; Tsompanoudi et al., 2016). The second bucket is to share and build knowledge. Not only is pair programming one way to facilitate knowledge transfer among team members (Plonka et al., 2015; Xinogalos et al., 2019), but the collaborative nature of pair programming helps participants achieve advanced learning outcomes (Tsompanoudi et al., 2015). This is a financial benefit to the company because it's a process for turning junior devs into senior devs. The OP argues this could be done in code reviews; I would argue code reviews are a form of async pairing or computer-supported collaborative learning. Finally, the last bucket for goals of pair programming is to learn how to work as a team.

Each of these offers financial benefit. People are driven by autonomy, mastery, and purpose (Pink, 2009). In order to reduce attrition, if people's needs for autonomy, mastery, and purpose are met, they will likely stay. Building capacity within the team for knowledge, be it individual knowledge or mapping distributed cognition and building shared mental models amongst the team, creates a more high performing team. This is instead of a team of individuals who work alone and who spend time learning specialized things other members already know because they don't communicate or trust each other as a team (but that's another post). If a team can work together more smoothly there's reduced attrition, increased productivity, and they hit targets faster. This is an economic benefit at a higher level than the lone pair. As previously mentioned, assessing whether or not pairing is "worth it" is a nuanced conversation. Let's look at team and knolwedge building. Throughout you'll see how these also facilitate improved problem solving which is the core purpose of pairing in the first place.

Team Building

Pair programming is computer-supported collaborative learning and knowledge building and both of those are fundamentally social processes (Miyake and Kirschner, 2014; Scardamalia & Bereiter, 2014). Contemporary social presence research includes collaborative learning and community building of which pair programming would be a part (Whiteside & Dikkers, 2012). The contemporary definition of social presence is learners taking an active role in their own and peers’ construction of knowledge via an affectively-charged connectedness (Whiteside & Dikkers, 2012). Therefore, social presence is a key to successful pairing. The behaviors that reify Whiteside and Dikkers’s Social Presence Model (2012) can be used to establish social norms that fulfill the components of Miyake and Kirschner’s team learning model (2014) and offer insight into ways to foster a healthy collaborative environment when pair programming.

The Social Presence Model is comprised of five elements: affective association, community cohesion, interaction intensity, knowledge and experience, and instructor investment (Whiteside & Dikkers, 2012). The team learning model is comprised of four elements: psychological safety, task and social cohesion, task and outcome interdependence, and group potency (Miyake & Kirschner, 2014). Affective association is the emotional connections fostered through emotion, humor, sarcasm, paralanguage and self-disclosure. Community cohesion is the extent to which a group sees themselves as a community (Whiteside & Dikkers, 2012). Affective association and community cohesion can foster psychological safety, where group members feel free to share ideas and take risks (Miyake & Kirschner, 2014).

Whiteside and Dikkers (2012) suggest behaviors that facilitate affective association and community cohesion. Discussion of community issues, general icebreakers, and extended individual introductions can facilitate affective association while discussions and icebreakers about cultural differences and the use of a multicultural framework facilitate community cohesion (Whiteside & Dikkers, 2012). Setting clear expectations about communication reduces the likelihood of misreading social cues and therefore builds a rich environment for psychological safety. Juxtapose to this environment of psychological safety, is one rife with ambiguous social cues which can manifest reactive aggression and hinder the development psychological safety (McCreery et al., 2019). Likewise, a lack of psychological safety can manifest in behaviors like being concerned about slowing a partner down or fear of looking stupid for asking questions or lacking knowledge which can then lead to disengagement (Plonka et al., 2012).

Pair programming sessions become micro-opportunities to fine tune one's ability to work with specific team members and build rapport. To the OP's point about pair programming being detrimental because it's like having a backseat driver, those are, I agree, awful pairing sessions. Part of what I want to come out of my dissertation is recommendations on how we can offer better guidelines to maximize the effectiveness and developer satisfaction with pair programming. If you'd like to participate in upcoming studies I'm planning, please sign up on my mailing list.

Knowledge Building

Knowledge building is a sociocognitive process defined as an out-in-the-world production of theories, proofs, problem solutions, hypotheses and more (Scardamalia & Bereiter, 2014). Actions that reify knowledge creation include identification and clarification of problems, offering a different perspective on an issue, or providing supportive or disconfirming findings related to problems or hypotheses (Scardamalia & Bereiter, 2014). This co-construction of meaning also called mutually shared cognition builds a context that is efficient for group decision making (Miyake & Kirschner, 2014).

The OP argues that the overall strategy should be agreed to before you write any code. My question is how? How do we agree on that overall strategy? Do we go off in our own directions and decide on a strategy and then come back together with hopefuly the same strategy? To the OP's point, I do agree that developing the strategy outside of writing the code is a great idea. This reduces the cognitive load of representational holding (the mental load of holding images, ideas, or mappings in memory) using a strategy called synchronzing. Synchronizing is especially beneficial to novice developers and demonstrates effective mentorship.

Synchronizing is a strategy from media processing theory when narration and animation are presented at the same time in order to reduce the need to hold representations in memory (Mayer & Moreno, 2003). Rather than discussing the architecture of the code while also working on the development problem and expecting the novice developer to hold the architecture in memory, they can collaboratively create an integrated diagram of the architecture with which they will be working prior to beginning to write code. An integrated diagram has explanations built into the diagram instead of separate. Kalyuga et al. (1998) found that participants who were novice level performed better on assessments when provided with an integrated diagram from which to study compared with those provided just a diagram or a diagram with text separate from the diagram. This would give the novice developer a map of the system and allow them to more positively contribute to the session while reducing cognitive load attributed to representational holding. This is also the co-construction of knowledge that provides a focused opportunity for the novice developer to ask quesitons, restate understandings, and get clarification.

The OP also argues that pairs devolve into least common denominator performance. Part of this hinges on how we're defining performance. Is it the amount of code produced? Is it the lack of errors? Is it mean time to solution? More generally, in situations of psychological safety where it's the group norm to challenge thinking, groups will often produce better decisions than individuals as it's the routine in those environments to push back against assumptions (Salinger et al, 2008). The OP's point about it being more difficult to reach flow in a pair is discussed by Socha and Sutanto (2015) when they point out that flow was based on the study individuals. In fact in collaborative pairing situations, disruptions were shorter and the pair returned to their task more quickly compared to individuals.

Conclusion

Pairing should not be used 100% of the day. As an introvert, I find constant pairing exhausting. However, I also don't think and the literature supports this, that it's a detrimental practice when used for the right reasons at the right times. Baby and the bathwater and all that. In some non-existent world where all developers are exactly the same with the same skill levels, needs, ways of acquiring knowledge who work like little robots in isolation, sure, pairing won't work. The reality though is that we work with other people of varying skill levels in varying things and those people are people. We don't work with all people the same way. Pairing offers us the opportunity to build strong relationships with our team members, learn from one another, improve our social norms and understanding of one another, and well as write code that has fewer mistakes, and even make us happier doing so when it's done right and in the right circumstances. As I figure out what that is, I'll be sure to share.

References

Baheti, Gehringer, E., & Stotts, D. (2002). Exploring the efficacy of distributed pair programming. Extreme Programming and Agile Methods — XP/Agile Universe 2002, 208–220. https://doi.org/10.1007/3-540-45672-4_20

Hanks. (2008). Empirical evaluation of distributed pair programming. International Journal of Human-Computer Studies, 66(7), 530–544. https://doi.org/10.1016/j.ijhcs.2007.10.003

Kalyuga, S., Chandler, P., & Sweller, J. (1998). Levels of expertise and instructional design. Human Factors, 40(1), 1–17. https://doi.org/10.1518/001872098779480587

Mayer, R. E., & Moreno, R. (2003). Nine ways to reduce cognitive load in multimedia learning. Educational Psychologist, 38(1), 43–52. https://doi.org/10.1207/s15326985ep3801_6

McCreery, M. P., Krach, S. K., Bacos, C. A., Laferriere, J. R., & Head, D. L. (2019). Can video games be used as a stealth assessment of aggression? International Journal of Gaming and Computer-Mediated Simulations, 11(2), 40–49. https://doi.org/10.4018/ijgcms.2019040103

Miyake, H. Kirschner, P. A., & Sawyer, R. K. (2014). The social and interactive dimensions of collaborative learning. In The Cambridge Handbook of the Learning Sciences (Second, pp. 418-437). Cambridge University Press.

Paletz, S. B. F. & Schunn, C. D. (2010). A social-cognitive framework of multidisciplinary team innovation. Topics in Cognitive Science, 2(1), 73–95. https://doi.org/10.1111/j.1756-8765.2009.01029.x

Pink, D. (2009) Drive: The surprising truth about what motivates us. Riverhead Hardcover.

Rasmusson, J. (2002). Strategies for introducing XP to new client sites. Extreme Programming and Agile Methods — XP/Agile Universe 2002, 45–51. https://doi.org/10.1007/3-540-45672-4_5

Reiser, B. J., Tabak, I., & Sawyer, R. K. (2014). Scaffolding. In The Cambridge Handbook of the Learning Sciences (Second, pp. 44-62). Cambridge University Press.

Salinger, S., Plonka, L., & Prechelt, L. (2008). A coding scheme development methodology using grounded theory for qualitative analysis of pair programming. Human Technology: An Interdisciplinary Journal on Humans in ICT Environments, 4(1), 9–25. https://doi.org/10.17011/ht/urn.200804151350

Scardamalia, M., Bereiter, C., & Sawyer, R. K. (2014). Knowledge building and knowledge creation: Theory, pedagogy, and technology. In The Cambridge Handbook of the Learning Sciences (Second, pp. 397-417). Cambridge University Press.

Smith, M., Giugliano, A., & DeOrio, A. (2018). Long term effects of pair programming. IEEE Transactions on Education, 61(3), 187–194. https://doi.org/10.1109/TE.2017.2773024

Socha, D. & Sutanto, K. (2015). The 'pair' as a problematic unit of analysis for pair programming. Proceedings - 8th International Workshop on Cooperative and Human Aspects of Software Engineering, CHASE 2015, 64–70. https://doi.org/10.1109/CHASE.2015.16

Tsompanoudi, D., Satrazemi, M., & Xinogalos, S. (2015). Distributed pair programming using collaboration scripts: An educational system and initial results. Informatics in Education, 14(2), 291–314. https://doi.org/10.15388/infedu.2015.17

Tsompanoudi, D., Satratzemi, M., & Xinogalos, S. (2016). Evaluating the effects of scripted distributed pair programming on student performance and participation. IEEE Transactions on Education, 59(1), 24–31. https://doi.org/10.1109/TE.2015.2419192

Whiteside, A. L., & Dikkers, A. G. (2012). Maximizing multicultural online learning experiences with the social presence model, course examples, and specific strategies. Computer-Mediated Communication across Cultures, 395–413. https://doi.org/10.4018/978-1-60960-833-0.ch025

Xinogalos, S., Satratzemi, M., Chatzigeorgiou, A., & Tsompanoudi, D. (2019). Factors affecting students’ performance in distributed pair programming. Journal of Educational Computing 0Research, 57(2), 513–544. https://doi.org/10.1177/0735633117749432