Avoiding The Pitfalls: How Good Pairs Overcome Problematic Behaviors

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

Abstract—Background: Pair programming (PP) can have many benefits in industry. Researchers and practitioners recognize that successful and productive PP involves some skill that might take time to learn and improve.

Question: What are the elements of pair programming skill?

Method: We perform qualitative analyses of industrial pair programming sessions following the Grounded Theory Methodology. We look for patterns of problematic behavior to conceptualize key elements of what ‘good’ and ‘bad’ pairs do differently.

Results: Here, we report two elements of pair programming skill: Good pairs (1) manage to maintain their Togetherness and (2) keep an eye on their session’s Expediency. We identify three problematic behavioral patterns that affect one or both of these elements: Getting Lost in the Weeds, Losing the Partner, and Drowning the Partner.

Conclusion: Pair programming skill is separate from general software development skill. Years of PP experience are neither a prerequisite nor sufficient for successful pair programming.

I. INTRODUCTION

Pair programming (PP) is the practice of two software developers working closely together on one machine. Kent Beck characterizes it as “a dialog between two people trying to [...] program (and analyze and design and test)” which “is a subtle skill, one that you can spend the rest of your life getting good at” [2, p. 100]. Beck sees many benefits in this practice, such as higher code quality in less time [2, pp. 66–67]. He does not, however, elaborate on the aspects of the “skill” underlying these benefits; he merely alludes to the importance of communication and coordination [2, p. 141].

Much of pair programming research appears to be built on the assumption that PP does not involve any particular skill beyond general software development experience: A large experiment by Arisholm et al. [1], for instance, was set to determine PP’s effect on code quality and effort for junior, intermediate, and expert developers, but 93 of its 98 subject pairs had no prior pairing experience at all. A meta-analysis of PP effectiveness [7] later found only weak effects and high between-study variance, which indicates a number of not-understood (and hence uncontrolled) moderating factors including the “amount of training in pair programming” [7, Sec. 4], which the researchers expect to have a positive effect on pair performance.

To understand the differences between skillful and problematic pair programming, we perform qualitative analyses of industrial PP sessions. Here, we report two elements of PP skill we identified. We discuss related work in Section II, characterize our data and explain our research method in Section III, sketch our findings in Section IV, and provide a discussion and an outlook in Sections V and VI.