Observations and Suggestions for Pair Programming

Motivations

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.

Once started in a partnership, each partner must make a strong effort to work together in the team.

Of course, exceptional circumstances (e.g., illness, family emergencies, serious injury) arise that may be outside one's control.

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),

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

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 Individual100% 100%
Pair 80% 165%
Program 2 Individual100% 100%
Pair 57% 114%
Program 3 Individual100% 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, surveyed 41 programmers over 6 semesters

This document is available on the World Wide Web as

     http://www.cs.grinnell.edu/~walker/courses/pair-programming.html

created 15 August 2013
updated 15 August 2013, 10-15 January 2014
typo corrected 25 August 2016
Valid HTML 4.01! Valid CSS!
For more information, please contact Henry M. Walker at walker@cs.grinnell.edu.

ccbyncsa.png

Copyright © 2011-2014 by Henry M. Walker.
Selected materials copyright by Marge Coahran, Samuel A. Rebelsky, John David Stone, and Henry Walker and used by permission.
This page is under development and is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 United States License.