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
B. Anti-Pattern: Getting Lost in the Weeds
Two developers may come up with more ideas on what to look up and how to proceed than a single developer. But pairs risk Getting Lost in the Weeds when they jump on too many of them with too little consideration. Such pairs may manage to Stay Together in that they both think about all these new ideas together, but they risk thinking too much about irrelevant details, losing track of what is important, and thus reduce their Expediency.
Example 1: Session DA2 (09:00–19:00). It is developer D4’s first week at the company, and he and D3 are tasked with implementing a new feature. D3 wants to explain the target state by showing a similar, already existing function. While D3 scrolls through the source code, D4 repeatedly interrupts him with questions unrelated to their task, and D3 always tries his best to provide all the information he can (highly compressed excerpt follows):
D3: “In principle, there should be a toolbar up here […] I’ll show you how it looked in the old calendar. [starts navigating in the source code]”
D4: “[reading from screen] What are these navigation things for? Are these Actions? Where are they displayed?”
D3: “[stops navigating] There is a—What’s it called again? [starts searching through package tree …]”
D4: “[later: reading from screen, chuckling] LicenseKey?”
D3: “[stops searching] You’ll see that more often around here […] let’s see where it’s used [starts fulltext search …]”
Since D4 is new at the company, providing him with information about the code base could be a good thing even if not pertinent to the current task. However, none of the side-topics actually led to D4 understanding something he did not already know (not shown above), so we characterize this as a case of a pair running into trouble (as defined in Section III-C). Instead, the main topic (i.e., explaining the target state to D4) is interrupted by twelve(!) abrupt topic changes (only two of which are shown above). Finishing an exchange with a net time of 30 seconds takes the pair about ten minutes—and it could have been even worse, as D3 was nearly lost after five minutes and only found his way back because a stacktrace happened to be displayed on-screen:
D3: “OK. Now, where were we? [looks around, sees stacktrace on lower display corner] Ah, the exception, right.”
Authors:
(1) Franz Zieris, Institut fur Informatik, Freie Universitat, Berlin Berlin, Germany ([email protected]);
(2) Lutz Prechelt, Institut fur Informatik. Freie Universitat Berlin, Berlin, Germany ([email protected]).
