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
E. Doing the Right Thing
Good pairs maintain Togetherness and Expediency; they avoid the three negative patterns described above.
For the case of Getting Lost in the Weeds, both pair members are responsible for restraining their impulses of following new ideas right away. If good pairs get side-tracked, they notice it and work their way back together, as in the next example.
Example 4: Session JA1 (04:00–06:40). Early in the session, a simple question by J1 interrupts an explanation by J2, which leads to a misunderstanding that takes almost two minutes to clear up. To avoid Getting Lost in the Weeds, both partners explicitly switch back to the original topic (last two lines in the excerpt):
J2: “There is the central [News] plugin and multiple processors which each handle one wave. […] It checks how the file size is changing.”
J1: “In what time window are you looking?”
[… two minutes of misunderstanding …]
J1: “30 seconds, that’s what I wanted.”
J2: “That’s 30 seconds long, the time window. Now I got you. I can show it to you [in the code] in a minute.”
J1: “Yes. And the NewsPlugin is doing what in all of this? Does it do exactly this monitoring and the delegation to the individual wave plugins, or what?”
J2: “No. The NewsPlugin basically only does—it gets called periodically by the cron server […]”
In contrast to Getting Lost in the Weeds, which the partners do together, Losing or Drowning the Partner is asymmetrical: One pair member is doing something ‘wrong’ to her partner (i.e., explaining too little or too much) who should then try to avert the problem. The next two examples show how good pairs agree on which topics to address and how to limit the scope of an explanation.
Example 5: Session DA2 (1:30:50–1:38:00). After their somewhat chaotic start (see Example 1 in Section IV-B), the session of D3 and D4 proceeds more orderly. Newly hired D4 explicitly asks his partner multiple times whether he should provide an explanation on some matter, which D3 agrees to:
D4: “Do you know about OSGi class loading?”
D3: “Class-what? Not really, no.”
D4: “Should I tell you?”
D3: “Sure.”
Example 6: Session JA1 (13:15–13:45). J2 explains code he wrote earlier to J1, who limits the explanation’s scope:
J2: “It comes from the function ‘getLastFile()’. […] Shall we look into the function or not?”
J1: “No, not now, please.” J2: “Not now, ok.”
In both cases, the developers make sure to neither Lose nor Drown their partner.
F. Further Elements of Pair Programming Skill
We found more elements of pair programming skill which we do not report here, e.g., Agreeing on a Common Plan, which includes picking up on cues that the partner did not understand one’s ideas. Failure to do so threatens the pair’s Togetherness and their work’s Expediency.
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]).
