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
D. Anti-Pattern: Drowning the Partner
The opposite behavior is also a problem. Just as one pair member may provide too little explanation, she may also Drown the Partner in too many explanations that (a) go far beyond the task and are hence not expedient and (b) also threaten the pair’s Togetherness.
Example 3: Session PA3 (29:50–31:40). Developers P1 and P3 just extracted multiple occurrences of the value 0.01 that is used in several percentage calculations into a constant. P1 starts a long-winded explanation which his partner does not understand because it is built on hypotheticals and does not relate to their actual code changes. P3 gets increasingly frustrated over the course of two minutes:
P1: “It’s important to make clear that the last two ‘0.01’ have no relationship.”
P3: “Which last two?”
P1: “The last two in lines 31 and 32, for example. Assuming the two numbers would have no relation and someone who only sees the implementation with raw numbers thinks ‘Oh, there is a relation, I’ll introduce a constant’ […].” [… P1 goes on for 40 seconds …]
P3: “But applied to our case this has no relevance.”
P1: “Yes, it has. Because it is a Magic Number, and Magic Number means”—P3: “But it is no longer ‘magic’. We just named it!” P1: “I wanted to explain why we are doing this”—P3: “[annoyed] I got that.”—P1: “I only want to clarify that it’s important to”—P3: “[annoyed, staring at screen] Got it.”— P1: “make the relation with this renaming. […] Not only to rename the variable.” P3: “[annoyed] It’s ok.”
In general, these two developers are getting along great, but here P1 was Drowning his Partner with explanations the partner neither wanted nor needed. After the session, the two developers talked about that incident. P3 criticized P1 for providing such “unwanted lectures” too often, continuing “If I didn’t know you better, I’d perceive this behavior as arrogant”. P1 responded that some issues just need pro-active explanations, because the partner would not even know what to ask, or when. Both agreed on this and continued working productively the next day.
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]).
