Cooperation, Collaboration and Pair-Programming: Field Studies on Backup Behavior - Franz Zieris
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Cooperation, Collaboration
and Pair-Programming: Field
Studies on Backup Behavior
Franz Zieris
franz.zieris@fu-berlin.de 1
Reminder
This paper is a peer-reviewed and
accepted journal article.
– Status is Corrected Proof:
“Articles in Press that contain the authors'
corrections”.
2
Aim? Identify situations in which pair programming is likely to be truly
needed and thus most beneficial.
How? Study and classify a broad range of developer interactions,
evaluating them for type, purpose an patterns of occurrence.
What? Two studies: Students and professionals, both of them free to
interact as they liked.
Results: Solo work is important component of team work.
Team interactions have two purposes:
Cooperation & Collaboration.
Collaborative behavior occurs much less often.
Mandatory Pair Programming may be less efficient.
3
Let’s start reading …
4
Definitions
• Backup Behavior:
5
Definitions
• Backup Behavior:
– Deutsch: Unterstützung, Beistand
6Definitions
• Backup Behavior:
– For the authors, all PP is backup behavior
7Definitions
• Collaborative & Cooperative Activities:
8OK, so what did they do?
9The Study
• Development Team:
– eXtreme Programming (but PP is optional)
– 10 developers, 10-15 years experience
– 3 issue types (user stories, bugs, tasks)
– each issue: 1 responsible developer
• Policy: sessions last 25 minutes max.
– team had been using a timing software for
several month
– start: enter developer name(s) and issue ID
– after 25 min: notification window pops up
10The Data
• Recorded 4915 sessions
– length: 1 to 25 minutes
– content: issue ID and participating devs
– 4001 solo sessions, 914 BB (pair) sessions
• Related to 300 issues
– each of them has a sequence of sessions
– 200 of them are shorter than 25 sessions
11Patterns
12Pattern SB
13What about
Cooperation/Collaboration?
14Pattern SB: Coop./Collab.
Collaboration
22 ≥ 5 BB
12
10 Cooperation
< 5 BB
2
5
4
4
2
15Cooperation/Collaboration
• The authors’ consideration:
Less than five pair-sessions per issue task nature
requires little involvement cannot be true collaboration
it is cooperation
• Consequence (not discussed):
– Four pair sessions (2:00 h) to fix a bug is “cooperation”.
– Five pair sessions (1:30 h) plus one solo session (0:30 h) to fix
a bug is “collaboration”.
• Maybe: distribution of BBs/issue actually has two clusters,
and 5 is a good discriminator, but:
– This is, at best, implied in the text.
– It’s unlikely, because from the 8 SB-patterned-issues:
5 BBs (1x), 4 BBs (2x)
– Even if there were two clusters and a good discriminator: That
says nothing about the meaning of the clusters.
• The authors themselves say that cooperation and collaboration have
no clear boundary and that only “shared goals” – something really
difficult to observe – make collaboration “collaborative”. 16All Patterns: Coop./Collab.
17Remainder of the study
red + yellow: the
developer worked
on n issues during
which he received
help from another
“Four developers
without
collaboration.”
i.e. with no issue
that was worked on
in more than 5 pair
sessions
What does this plot
display anyway?
18Remainder of the study
“To better
understand the
various working
styles.”
Same plot as
before, but
normalized for
each developer.
Again, what
does it show?
19Remainder of the study
“To better visualize the
amount of effort involved in
solo, collab. and coop.
development”
So far: coop./collab. was
determined for issues, now it is
for sessions.
I.e. the same four sessions
would be either coop. or
collab. depending on whether
or not there is another pair-
session for this issue.
20Conclusions of the Study
• Developers work in pairs, even without
being forced to do so (40% of their time).
• Distinction between cooperation and
collaboration is important.
• The patterns have similar occurrences so
they reflect natural behavior.
• Developers sense the higher cost of
collaboration (compared to cooperation)
and therefore avoid it.
21Distinction between cooperation and collaboration is important. The patterns have similar occurrences so they reflect natural behavior. Developers sense the higher cost of collaboration 22
But wait a second …
• We just took a look a the 2nd study.
• There was another one, involving
two 5-person teams of students.
23Data Collection
• 1st study: do something, when finished, create
record of what happened.
• 2nd study: create record with issue ID and
persons, do something, after 25 minutes either
stop it or start a new session
24Pattern extraction
Patterns Available and used How to create
data of 1st study session sequences?
Sequence:
Sessions of an issue
25Problem List
1. Distinction between Coop./Collab. is highly
questionable.
2. The purpose of the 1st study is unclear: the
extraction of the pattern is not described,
maybe even impossible.
3. The company uses the recorded data (devs,
time, issue) for “accounting” and “software
engineering purposes”.
– If persons are measured individually, they are less
likely to engage in group activities damper for
pair programming, but not discussed in the paper.
4. The effects of the 25+5 rule are not discussed.
5. Reference to previous publications raises more
questions (see next slide) 26Re-use of data
• Coman et al. (2014):
– 9 months, 10 developers
– Sessions: 25+5 minutes policy What does “some of
• Fronza et al. (2009): the same data” mean?
– 10 months, 15+2 developers Same team?
– Sessions: “enter data per story point”
• Coman et al. (2008):
– 3 months, 14+2 developers
– Sessions: “enter data on start, stop whenever they finish”
• In each study:
– Devs. are 30-40 year old Italians with university degrees in
computer-related areas, 10-15 years experience, and mainly
using C#
27Problem List (c’d)
6. Suboptimal choices of examples for an
interest in pair programming application.
22
12
8 SB-patterned issues,
10
total of 61 BB sessions:
~7-8 BBs/issue
2
5
4 43 other-patterned issues
4
2 (Sg, BO, Bg, BS, & MX),
total of 853 BB sessions:
~20 BBs/issue
28Problem List (c’d)
7. No distinction between bug, feature, task
– everything is an issue
8. Very little information about the distribution of:
– (pair) sessions per issue
– session length, issue length
– developers per issue (always the same pair?)
– work mode per developer (in hours)
9. Unjustified claims (not presented/not possible):
– “PP is used to overcome unexpected difficulties.”
– “PP is closely related to task and team characteristics.”
29Problem List (c’d)
10. Unclear conclusions:
– “important coop./collab. distinction”
– “natural behavior leads to even pattern
distribution”
– “developers perceive higher cost of collab.
and therefore prefer coop. and solo”
11. No discussion of the nature of the
“backup behavior” – the only considered
facet is the negative impact on the
developer’s productivity.
30Abstract revisited
Aim? Identify situations in which pair programming is likely to be truly
needed and thus most beneficial.
How? Study and classify a broad range of developer interactions,
evaluating them for type, purpose an patterns of occurrence.
What? Two studies: Students and professionals, both of them free to
interact as they liked.
Results: Solo work is important component of team work.
Team interactions have two purposes:
Cooperation & Collaboration.
Collaborative behavior occurs much less often.
Mandatory Pair Programming may be less efficient.
31Reminder
This paper is a peer-reviewed and accepted
journal article.
But apparently reviewers are human after all.
32Thank you!
33You can also read
