In-Depth: How To Make Pair Programming More Effective

The role of personality, task complexity, experience, and communication skills on the effectiveness of pair programming

Pair programming is a common practice in Agile teams. Although it has been around for a long time (Coplien, 1995), it was popularized by Kent Beck as part of Extreme Programming (XP) (Beck & Andres, 2004). In its formal form, two developers work together at a single workstation on a single problem (Beck, 2004). In this pair, one developer acts as the driver and writes the code while the other is the navigator and reviews each line of code. These pairs should be dynamic in that partners switch with other pairs frequently to spread learning across the team.

As we showed in the previous article, the scientific evidence from meta-analyses overwhelmingly shows that pair programming is beneficial for quality and learning, especially for junior and intermediate developers, and particularly for complex tasks (Salge & Berente, 2016; Hannay et. al., 2009). However, pair programming tends to be slower than solo programming if the duration is considered, although this difference may diminish as developers get used to pairing (Williams et. al., 2000).

So pair programming is clearly an investment where additional person-hours are traded for increased quality, more learning, and hopefully increased speed in the (near) future. But what makes one session of pair programming more effective than another?

“But what makes one session of pair programming more effective than another?”

Several academic investigations have attempted to shine a light on this from different angles. We will discuss the impact of personality traits, task complexity, experience, and communication patterns.

This post is part of our “in-depth” series. Each post discusses scientific research that is relevant to our work with Scrum and Agile teams. We hope to contribute to more evidence-based conversations in our community and a stronger reliance on robust research over personal opinions. As you may imagine, it takes a lot of time to compile such evidence-based posts. If you think our content is valuable, and you think we should write more of it, you can support us on Patreon.

Perspective #1: Personality Types

Many studies of pair programming have investigated the role of personality. The underlying belief is that personality traits, like introversion, open-mindedness, or extraversion, influence the ability of developers to pair effectively. Another expectation is that developers that bring different traits to pairing are more effective than developers who bring similar traits. So a pair where one is introverted and the other is extroverted are expected to be more effective than pairs where both are introverted, or extroverted.

The Meyers-Briggs Type Indicator (MBTI) remains popular in business settings and has been used frequently in comparative studies. However, most studies found no effect (Katira et. al. 2004; Layman, 2006) or only a small one (Chao et. al. 2006, Visram, 2004). One reason for the lack of effect may be that the MBTI has a poor conceptual grounding, low reliability, and lacks validity (Furnham, 1996). It has been described as a modern form of astrology, where personality types are described in such vague terms that anyone can recognize themselves in them (“Forer Effect”, Forer, 1949). However, other studies that used more reliable and valid personality indicators like the Big Five have also failed to find a meaningful effect of personality on pair programming (Salleh et al. 2010). Hannay et. al. (2009) studied 98 pairs of developers and found no meaningful effect of the Big Five personality types (e.g. openness, introversion, neuroticism, conscientiousness).

Pair programming usually has one developer act as the “driver” while the other is the “navigator”. Picture by Christiaan Verwijs.

So what does this mean? The evidence suggests that it is more fruitful to focus on contextual factors, like task complexity, experience, and learning, than on personality as a factor in pair programming. The upside of this is that such factors can be changed or trained by teams and organizations, whereas personality traits can’t be changed. This fits well with the overall finding of social psychologists that contextual factors are more relevant to actual behavior than personality traits. See Ross, Nisbett & Gladwell (2011) for an extensive discussion on this.

“The evidence suggests that it is more fruitful to focus on contextual factors, like task complexity, experience, and learning, than on personality as a factor in pair programming.”

Perspective #2: Task Complexity & Experience

A second perspective on pair programming puts focus on contextual factors, primarily task complexity and the experience of developers (seniority). These studies generally ask computer science students or professional developers of varying levels of seniority to pair on tasks of varying complexity.

A summary of 18 of these empirical studies is offered in a meta-analysis by Hannay et. al. (2009). They found that developers of junior and intermediate experience see big leaps in quality when they pair, particularly for complex tasks. However, the quality of code that is produced by senior developers doesn’t improve meaningfully when pairing on complex tasks. In fact, code quality drops slightly when senior developers pair on simple tasks. This is mostly consistent with another meta-analysis by Salge & Berente (2016). Based on the results to date, Dyba et. al. (2009) conclude: “Two heads are better than one for achieving correctness on highly complex programming tasks. They might also have a time gain on simpler tasks”.

“They found that developers of junior and intermediate experience see big leaps in quality when they pair, particularly for complex tasks.”

But how should pairs be composed? Is it better to mix senior and junior developers, or to keep the skill level similar? One study by Bowman et. al. (2019) among 587 students suggests that a big gap in experience may be counterproductive. The authors report that the less experienced partner contributed less, learned less, and exerted lower effort when paired with highly skilled developers. Other studies have found similar results (Chaparro et. al., 2005, Katira et. al., 2005). A limitation of these studies is that they rely on student samples, so we can’t immediately generalize the results to the workplace. However, a survey study of 106 developers at Microsoft also shows that developers prefer partners with a similar level of experience (Begel & Nagappan, 2008).

So what does this mean? In practice, pair programming seems most useful for complex tasks or when developers lack experience. The evidence-based recommendation is to avoid pairings between developers with very different levels of experience (e.g. junior and senior).

“The evidence-based recommendation is to avoid pairings between developers with very different levels of experience (e.g. junior and senior)”

Perspective #3: Communication Skills

A third perspective looks at how pairs communicate and interact. In its most formal approach, pair programming requires one developer to act as the driver who writes code and the other as the navigator who makes suggestions and reviews on-the-fly (Beck, 1999). Interestingly, some field studies suggest that such a strict separation rarely happens in practice, and may actually be counter-productive (Chong & Hurlbutt, 2007).

Zarb & Hughes (2015) systematically observed 71 pair programming sessions in three contexts to learn how developers interact. In particular, they noticed how pairs frequently offered suggestions that emerged from three different patterns. For each pattern, the authors developed guidelines to make them more effective. They then tested whether or not these guidelines actually improved pair programming in the second phase of their study, and in a follow-up study (2015b). This makes the findings from these studies very useful to developers who practice pair programming.

Pattern #1: Planning

This first pattern begins with a suggestion by the navigator or the driver to review existing code. A typical example could be “I don’t understand what is happening in this for-each loop”, or “Let’s take a step back and review our code”. The developers then talk about the code, which in turn leads to a new suggestion on what to modify, e.g. “Why don’t we try to remove the if-then within the for-each by ….”.

Zarb & Hughes (2015) identified three guidelines to make this pattern more effective for developers:

1. Both as driver and navigator, feel free to communicate about whatever could move you forward.
2. As a driver, ask for clarification if a suggestion is unclear. As a navigator, ask for clarification when you don’t understand why the driver is writing what they are writing.
3. Both as driver and navigator, repeat in your own words what your partner said to verify if you understand each other correctly.

Pattern #2: Action

This second pattern happens when pairs actively write code. The authors observed that drivers often start “muttering” to verbalize what they are writing, while navigators are helping.

Zarb & Hughes (2015) identified three guidelines to make this pattern more effective for developers:

1. As the driver, verbalize what you are thinking and doing (“muttering”). This gives more opportunities for navigators to help, support, and suggest.
2. As the navigator, observe what the driver is typing and make suggestions to improve the code where you can.
3. As the navigator, follow the verbalizations of the driver to understand what they are writing.

Pattern #3: Restarting

Finally, the third pattern is when pairs purposefully unfocus from their work. The authors observed many instances where developers made unrelated jokes, mentioned family events, talked about unrelated topics, or just went silent for a while. Sometimes this was in response to being stuck.

Zarb & Hughes (2015) noted that this pattern was useful for many developers to get unstuck, or to see new possibilities after a brief interruption. They identified three guidelines to make this pattern more effective for developers:

1. As the navigator, notice when the driver appears to be stuck for a while and actively unfocus by talking about something unrelated.
2. As the driver or the navigator, don’t dismiss it when the other tries to unfocus. Instead, follow, and then bring it back the code eventually.
3. As the driver or the navigator, follow up this pattern with: a review of recent steps, identify a fresh start or reflect on the end goal to inform the next step.

In our case, we often restarted by making ourselves a good cup of coffee downstairs

Evaluating the patterns

After the identification of the patterns and the guidelines, Zarb & Hughes (2015) then tested them with 28 participants. Half of the pairs were trained in the guidelines while the other half were not. The pairs who followed the guidelines reported significantly higher contributions to their partner and found it significantly easier to communicate during pairing. No significant difference was found for the number of complete tasks, however. A follow-up study (Zarb & Hughes, 2015b) found stronger effects of exposure to the guidelines. “Ease of communication” and “Perceived partner contribution” was evaluated almost 1 point higher (on a scale from 1–5) by developers who were trained in the guidelines.

The authors also interviewed the pairs afterward and found that the pairs had little trouble adopting the guidelines. Although most of this happened naturally, awareness of the guidelines helped developers move through the patterns and be more responsive to each other. These findings show that pair programming, and particularly awareness of the interaction patterns that make it effective, are important skills for Agile teams.

“These findings show that pair programming, and particularly awareness of the interaction patterns that make it effective, are important skills for Agile teams.”

Discussion: Pair Programming Is A Skill

Taken together, there is ample scientific evidence to pinpoint the factors that are most relevant to the effectiveness of pair programming. Personality is not a meaningful factor. But the complexity of tasks is. And so is the experience of developers, and the gap in experience between pairs.

But obviously, most of what makes pair programming effective lies in how developers interact in their pairs. The three interaction patterns identified by Zarb & Hughes (2015) evidently make developers more effective when they are aware of them, particularly when they follow the guidelines developed by these authors.

Developers can learn the skills to effectively pair on tasks. Illustration by Thea Schukken.

Zieris & Prechelt (2021) also emphasize the value of communication skills. They observed that effective pairs focus on maintaining a shared mental model (togetherness) and balance short-term goals with long-term goals (expediency). However, ineffective pairs exhibit three problematic patterns that damaged togetherness and expediency:

1. Partners get lost in the weeds when they get lost in details.
2. A partner loses the other when they fail to explain what they are doing.
3. A partner drowns their partner by explaining too much.

This research provides clear practical guidance for how to train and develop the skills of developers to more effectively pair. It also shows that pair programming itself is a skill that is separate from coding skills, and needs to be developed on its own. This may also explain why pairs that work together more tend to become more effective over time (“pair jelling”, Williams & Kessler, 2003).

“This research provides clear practical guidance for how to train and develop the skills of developers to more effectively pair.”

Practical Recommendations

So what does all this mean in practice? Below, we outline recommendations that make the most sense in light of the evidence. We duplicated some from our earlier article in case you missed that one.

Recommendation #1: Encourage pairing on complex tasks

The evidence suggests that pairing is most beneficial for complex tasks, although the most junior developers also benefit from pairing on simpler tasks. For more experienced developers, pairing on simple tasks may even lead to worse outcomes than solo programming (Hannay et. al., 2009).

Thus, the evidence does not support the belief that pairing should be used to write all code, as recommended initially (Beck, 1999). Instead, as a tool, pair programming appears to be best suited for complex problems and to help developers who lack the experience to write good code on their own. Of course, the judgment of what is complex progresses along with experience. So this is ideally a judgment that teams should make together as they coordinate their work. The Daily Scrum is an ideal opportunity to make such judgments and issue pairing invitations.

Recommendation #2: Avoid big experience gaps

Most academic studies suggest that the pairing of developers with different levels of experience is more beneficial, as long as the gap is not too large. However, junior developers who are paired may also be more effective together than alone for tasks that are not too complex. Otherwise, there is the risk of the “blind leading the blind”. However, pairing a developer with very low experience with a developer with tons of experience also doesn’t seem to be very effective (Hannay et. al., 2009, Bowman et. al. 2019). So if you have the option, form pairs of mixed experience that are not too far apart.

Recommendation #3: Make work agreements

Good communication is clearly essential to pair programming (Zarb & Hughes, 2015). As with all the work that happens in teams, it is useful to make critical work agreements to make such interactions enjoyable and effective. For pair programming specifically, the patterns and guidelines by Zarb & Hughes (ibid) that we shared in this post are useful. Alternatively, you can make your own. You can find many tips in this in-depth article on the science of work agreements. Examples of such work agreements could be:

• “Tasks that are most suited to pair programming in our team are …“
• “We can invite others to pair with us by …“
• “We limit our pair programming sessions to … minutes”

Recommendation #4: Treat Pair Programming As A Skill

The evidence in this post clearly supports the belief that pair programming is a skill that needs to be learned. In particular, developers have to become aware of how to maintain togetherness and expediency. A good approach to this would be to teach the different problematic patterns that were identified by Zieris & Prechelt (2021); getting lost in the weeds, losing each other, and drowning the other. Additionally, developers can be trained in the guidelines that Zarb & Hughes (2015) identified for the three patterns in pair programming; planning, action and restarting.

Conclusion

Pair programming has been a staple of Agile teams. Not everybody likes it. But many developers enjoy the experience once they’ve tried it. More importantly, pair programming can result in higher-quality code and more learning when it is practiced properly.

In this post, we explored scientific studies of what makes pair programming more (or less) effective. This is a continuation of a previous post in which we explored the cost and benefits of pair programming.

Despite the wealth of research, there is still much we don’t know. We don’t know how pair programming affects the overall cycle time of work. It is also unclear how productivity improves as developers pair together more. A lot of the research is based on student samples, mostly because it is hard to gain access to professional developers on a large-enough scale. It would be incredible if more organizations would be willing to support, fund, and perform this kind of research so that we can all learn from it.

We hope this post gives you a better evidence-based way to try and improve pair programming in your team and organization. Enjoy!

This post took over 23 hours to research and write. If you think our content is valuable, and you think we should write more of it, you can support us on Patreon. Find more evidence-based posts here.

We thank all the authors of the referenced papers and studies for their work.

Writing an investigative post like this takes a lot more time than an opinion piece. We have to delve through many scientific papers, collect data and compile it into something readable. The analyses and writing of this post took over 23 hours. So we’d be deeply grateful for your support. Check out patreon.com/liberators to support our free blog posts, podcasts, the development of the Scrum Team Survey, and more.

References

Beck, K., & Andres, C. (2004). Extreme programming explained: Embrace change. 2-nd edition.

Begel, A., & Nagappan, N. (2008, October). Pair programming: what’s in it for me?. In Proceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement (pp. 120–128).

Bowman, N. A., Jarratt, L., Culver, K. C., & Segre, A. M. (2019, July). How prior programming experience affects students’ pair programming experiences and outcomes. In Proceedings of the 2019 ACM Conference on Innovation and Technology in Computer Science Education (pp. 170–175).

Chao, J., & Atli, G. (2006). Critical personality traits in successful pair programming. In AGILE 2006 (AGILE’06) (pp. 5-pp). IEEE.

Chaparro, E. A., Yuksel, A., Romero, P., & Bryant, S. (2005, June). Factors Affecting the Perceived Effectiveness of Pair Programming in Higher Education. In PPIG (p. 2).

Chong, J., & Hurlbutt, T. (2007, May). The social dynamics of pair programming. In 29th International Conference on Software Engineering (ICSE’07) (pp. 354–363). IEEE.

Coplien, J. (1995). A development process generative pattern language. Pattern Languages of Program Design.

Forer, B. R. (1949). The fallacy of personal validation: a classroom demonstration of gullibility. The Journal of Abnormal and Social Psychology, 44(1), 118.

Furnham, A. (1996). The big five versus the big four: the relationship between the Myers-Briggs Type Indicator (MBTI) and NEO-PI five-factor model of personality. Personality and individual differences, 21(2), 303–307.

Hannay, J. E., Dybå, T., Arisholm, E., & Sjøberg, D. I. (2009). The effectiveness of pair programming: A meta-analysis. Information and software technology, 51(7), 1110–1122.

Hannay, J. E., Arisholm, E., Engvik, H., & Sjoberg, D. I. (2009). Effects of personality on pair programming. IEEE Transactions on Software Engineering, 36(1), 61–80.

Katira, N., Williams, L., Wiebe, E., Miller, C., Balik, S., & Gehringer, E. (2004). On understanding compatibility of student pair programmers. In Proceedings of the 35th SIGCSE technical symposium on Computer science education (pp. 7–11).

Layman, L. (2006). Changing students’ perceptions: an analysis of the supplementary benefits of collaborative software development. In 19th Conference on Software Engineering Education & Training (CSEET’06) (pp. 159–166). IEEE.

Ross, L., & Nisbett, R. E. (2011). The person and the situation: Perspectives of social psychology. Pinter & Martin Publishers.

Salleh, N., Mendes, E., Grundy, J., & Burch, G. S. J. (2010). The effects of neuroticism on pair programming: an empirical study in the higher education context. In Proceedings of the 2010 ACM-IEEE international symposium on empirical software engineering and measurement (pp. 1–10).

Salge, C. A. D. L., & Berente, N. (2016). Pair programming vs. solo programming: What do we know after 15 years of research?. In 2016 49th Hawaii International Conference on System Sciences (HICSS) (pp. 5398–5406). IEEE.

Visram, K. (2004). Extreme programming: Pair-programmers, team players or future leaders? In IASTED Conf. on Software Engineering and Applications (pp. 659–664).

Williams, L., & Kessler, R. R. (2003). Pair programming illuminated. Addison-Wesley Professional.

Zarb, M., & Hughes, J. (2015). Breaking the communication barrier: guidelines to aid communication within pair programming. Computer science education, 25(2), 120–151.

Zarb, M., Hughes, J., & Richards, J. (2015b). Further evaluations of industry-inspired pair programming communication guidelines with undergraduate students. In Proceedings of the 46th ACM technical symposium on computer science education (pp. 314–319).

Zieris, F., & Prechelt, L. (2021, May). Two elements of pair programming skill. In 2021 IEEE/ACM 43rd International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER) (pp. 51–55). IEEE.