Observations and Suggestions for Pair Programming
Motivations
- Almost continuous code review
- From Gerald
Weinberg, The Psychology of Computer Programming Silver Anniversary
Edition, Dorset House, New York, 1998, quoted by Laurie Williams:
"The human eye has an almost infinite capacity for not seeing
what it does not want to see.... Programmers, if left to
their own devices, will ignore the most glaring errors
in their output - errors that anyone else can see in
an instant."
- Working in pairs within a classroom setting grew out of innovative
software development methodologies, called eXtreme Programming (XP) and
agile methods, to address issues related to meeting customer needs,
software quality, reliability, software maintenance, and programmer burnout.
Basic Approach
Approach: 2 programmers collaborate utilizing two roles: Driver and
Navigator
| Driver
| Navigator
|
-
Controls pencil, mouse, keyboard
-
Responsible for details of developing or writing code
-
Makes reasoning/thought process clear and explicit by talking out loud
during development
-
Responds constructively to feedback by Navigator
|
-
Does not enter code; operates in hands-off mode
-
Continuously, actively observes the Driver
-
Checks for errors
-
Considers alternatives
-
Performs needed reference work
-
Considers long-term and strategic implications
- does this approach have potential pitfalls
- will this approach lead to dead ends
- is there a better way
|
Responsibilities
Although pair programming has substantial potential benefits for learning
and for software development, success in computer science courses requires
active collaboration.
-
Partners must treat each other as equals
-
Partners must switch roles regularly
-
Appropriate options to switch roles:
- for different tasks within day
- during in-class labs,
- at least every class period
- half way through each class period (preferred)
-
In some classroom settings, roles refined by mutual agreement, so
Driver controls the keyboard and Navigator controls the mouse.
Once started in a partnership, each partner must make a strong effort to
work together in the team.
-
Each partner should come to class and actively participate throughout the
class session.
-
Partners should make arrangements to meet as needed in the lab outside of
class to finish labs or projects.
-
Each partner has an obligation to show up and actively participate during
out-of-class, planned sessions.
Of course, exceptional circumstances (e.g., illness, family emergencies,
serious injury) arise that may be outside one's control.
-
When such situations, the afflicted individual should contact both the
partner and the instructor as soon as is reasonably possible. (Email is
fine.)
-
These exceptional circumstances do not include situations that could
reasonably be known ahead of time (e.g., academic activities, athletic
events).
Failure to comply with one's responsibilities as a partner may have a
substantial impact on one's semester grade. Not only is the irresponsible
party neglecting their own education, but they also are having a negative
impact on the education of their partner(s).
For example, excluding exception circumstances (e.g., health),
-
Abandoning a partner in the middle of a class session or for a follow-up lab
session may result in the lowering of a semester grade by 1/3 letter or
more.
-
Repeated negligence may result in the instructor petitioning the Committee
on Academic Standing to drop the student from the course (as interfering
with the learning of others in the class).
Some Results
Many studies compare use of pair programming with individual programming,
both in industry and in academic setting. Results of two early (but
typical) studies follow.
Research by John T. Nosek
"The Case for Collaborative Programming", Communications of the ACM, Volume
41, Number 3, March 1998, pp. 105-108.
Timed assignment to write a script to check database consistency
-
15 full-time systems programmers in a program trading firm
-
Based on random personnel assignments:
-
5 subjects worked alone
-
10 subjects worked in pairs (5 pairs)
-
Unix-based networks, working in C
-
Problem critical to organization's success, so motivation high
-
Task targeted for 45 minutes
-
Time required measured by stopwatch
-
Two graders separately graded functionality and readability, with 90%
grading consistency
- Post-experience questionnaire asked each person to rate
- confidence about their work
- enjoyment of the process
Comparison of Individual and Team Measurements
| Variable
| Control Group
(Individual)
mean (st. dev.)
| Experimental Group
(Teams)
mean (st. dev.)
| Scale
|
Performance
Scores:
| n = 5
| n = 5
|
|
| READABILITY
| 1.40 (0.894)
| 2.00 (0.000)
| 0 to 2
|
| FUNCTIONALITY
| 4.20 (1.788)
| 5.60 (0.547)*
| 0 to 8
|
| SCORE
| 5.60 (2.607)
| 7.60 (0.547)*
| 0 to 8
|
| TIME (minutes)
| 42.60 (3.361)
| 30.20 (1.923)
|
|
| | | |
|
Satisfaction
Measures
| n=5
| n=10
|
|
| CONFIDENCE
| 3.80 (2.049)
| 6.50 (0.500)*
|
|
| ENJOYMENT
| 4.00 (1.870)
| 6.60 (0.418)*
|
|
* less than 1 in 20 that results are due to chance
Research by Laurie Williams, Robert Kessler, Ward Cunningham, and Ron
Jeffries
"Strengthening the Case for Pair Programming",
IEEE Software, Volume 17, July 2000, pp. 19-25, and
http://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftware.PDF, based on first three assignments (41 students)
at the University of Utah
Quality
| Assignment | Group | Elapsed Time | Total Time |
| Program 1 | Individual | 100% | 100% |
| Pair | 80% | 165% |
| Program 2 | Individual | 100% | 100% |
| Pair | 57% | 114% |
| Program 3 | Individual | 100% | 100% |
| Pair | 58% | 116% |
|
Quality
Percentage of Test Cases Passed
| | Individuals | Pairs
|
| Program 1 | 73.4 | 86.4
|
| Program 2 | 78.1 | 88.6
|
| Program 3 | 70.4 | 87.1
|
| Program 4 | 78.1 | 94.4
|
The difference in quality levels is statistically significant to p < 0.01;
p is the probability that these results could occur by chance.
|
Satisfaction
In the university study that surveyed 41 programmers over 6 semesters,
-
over 90% indicated they enjoyed collaborative programming more
than working alone
-
almost 95% indicated they had more confidence in their code when
working in pairs.
This document is available on the World Wide Web as
http://www.walker.cs.grinnell.edu/courses/pair-programming.html
created 15 August 2013
updated 15 August 2013, 10-15 January 2014
typos corrected 25 August 2016, 20 January 2018
|
|
|
For more information, please contact
Henry M. Walker at
walker@cs.grinnell.edu.
|
