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."
- Pair programming within a lab-based course 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 |
|---|---|
|
|
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
|
Quality
The difference in quality levels is statistically significant to p < 0.01;
|
Satisfaction
In the university study, 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.
|
created 15 August 2013 updated 15 August 2013, 10-15 January 2014 refined and reformatted 10 March 2016, 5 May 2016 |
|
| For more information, please contact Henry M. Walker at walker@cs.grinnell.edu. |
