Table of Links

Abstract and I. Introduction

II. Related Work

A. On the Existence of Pair Programming Skill

B. On the Elements of Pair Programming Skill

III. Research Method

A. Research Goal and Data Collection

B. Qualitative Research Approach

C. Our Notions of ‘Good’ and ‘Bad’

IV. Results

A. Two Elements of Pair Programming Skill

B. Anti-Pattern: Getting Lost in the Weeds

C. Anti-Pattern: Losing the Partner

D. Anti-Pattern: Drowning the Partner

E. Doing the Right Thing and F. Further Elements of Pair Programming Skill

V. Discussion

VI. Summary and Future Work

VII. Data Availability and References

VI. SUMMARY AND FURTHER WORK

Pair programming (PP) does not just ‘work’ because two software developers sit next to each other. Rather, developers can be more or less skilled at pair programming. We characterize two elements of that skill that are independent from software development skills: Maintaining Togetherness and keeping an eye on Expediency. There are possibly more elements to be found. So far, we described three patterns of problematic behavior:

• Getting Lost in the Weeds, during which both partners stay together as a pair, but lose sight of which topics are worth pursuing.

• Losing the Partner, in which one pair member focuses too much on the task and explains too little.

• Drowning the Partner, in which one pair member explains too much, which may harm the pair’s Togetherness and Expediency.

Our current data is limited to snapshots of pair programmer behavior: Most pairs in the PP-ind repository [15] were recorded only once or twice during a short stretch of their pair programmer career. Nevertheless, we have already seen that prior PP experience alone does not explain beneficial and problematic behavior. Longitudinal research with the same developers over longer time frames will be needed to understand and disentangle the influence of developers’ personal styles, their day-to-day form, and their experience with pair programming in general or with a particular partner.