Pair Programming: Why Have
Two Do the Work of One
from
Laurie Williams
North Carolina State University
Pair Programming
Agenda

Research/Findings
 Colocated Pairs
 Distributed Pairs

Pair Interactions

Sample Pairings

Pair Rotation

Summary
Empirical Study for Validation
 Practice: Summer 1999
 20 Students (Sophomore/Junior)
 All worked collaboratively
 Generated more anecdotal/qualitative evidence
 Solo vs Pair: Fall 1999
 41 Students (Junior/Senior)
 28 Worked Collaboratively
 13 Worked Individually
 Software development process was controlled
 The only experimental variable: pair-programming
 Quantitative: Time, Quality, Enjoyment, Confidence
Post Development Test Cases Passed
100.0%
90.0%
80.0%
70.0%
60.0%
50.0%
40.0%
30.0%
20.0%
10.0%
0.0%
Individuals
Collaborators
Program 1
Program 2
Program 3
Program 4
Boxplot of Program Quality
Elapsed Time
120.0%
100.0%
80.0%
60.0%
40.0%
20.0%
0.0%
Program 1
Program 2
One Individual
One Collaborator
Program 3
Boxplot of Student Time
Collaboration by Phase
Collaborative
Individual
l
O
ve
ra
l
st
Te
le
Co
m
pi
w
Re
vi
e
e
Co
d
Re
vi
e
n
Co
de
w
n
De
si
g
De
si
g
Pl
an
ni
ng
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
ENJOY the w ork more because of Pair
Programming
100%
80%
60%
40%
20%
0%
PR OF
SU M 1
SU M 2
SU M 3
Agree
F A LL1
F A LL2
F A LL3
Disagree
More Confident in our Work When Pair Programming
100%
80%
60%
40%
20%
0%
PROF
SUM1
SUM2
SUM3
Agree
FALL1
Disagree
FALL2
FALL3
Distributed Pair Programming







Net Meeting
Yahoo Messenger
Graduate Object-Oriented class at NCSU
5-week project
132 students
34 distance students
Teams of 2-4 students
 Colocated non-pairs (9 groups)
 Colocated pairs (16 groups)
 Distance non-pairs (8 groups)
 Distance pairs (5 groups)
Productivity
Quality
Satisfaction with Working
Arrangement
Very
good
Good
Fair
Poor
Non-pair colocated
46%
40%
11%
3%
Pair colocated
62%
28%
10%
0%
Non-pair distributed
45%
37%
18%
0%
Pair distributed
83%
17%
0%
0%
Satisfaction with Communication
Very
good
Good
Fair
Poor
Non-pair colocated
57%
26%
11%
6%
Pair colocated
58%
28%
12%
2%
Non-pair distributed
41%
41%
14%
4%
Pair distributed
67%
33%
0%
0%
Research Findings to Date

Strong anecdotal evidence from industry
“We can produce near defect-free code in less than half the time.”

Empirical Study
– Pairs produced higher quality code
» 15% less defects (difference statistically significant)
– Pairs completed their tasks in about half the time
» 58% of elapsed time (difference not statistically significant)
– Most programmers reluctantly embark on pair programming
» Pairs enjoy their work more (92%)
» Pairs feel more confident in their work products (96%)
– Distributed pair programming is a viable alternative (worthy of
much more research)
How does this work?
 Pair-Pressure
 Keep each other on task and focused
 Don’t want to let partner down
 “Embarrassed” to not follow the prescribed process
 Parkinson’s Law “Work expands to fill all available time.”
 Pair-Negotiation
 Distributed Cognition: “Searching Through Larger Spaces of
Alternatives”
 Have shared goals and plans
 Bring different prior experiences to the task
 Different access to task relevant information
 Must negotiate a common shared of action
 Pair-Relaying
 Each, in turn, contributes to the best of their knowledge and ability
 Then, sit back and think while their partner fights on
How does this work (part two)?
 Pair-Reviews
 Continuous design and code reviews
 Ultimate in defect removal efficiency
 Removes programmers distaste for reviews
 80% of all (solo) programmers don’t do them regularly or at all
 Debug by Describing
 Tell it to the Furby
 Pair-Learning
 Continuous reviews  learn from partners techniques, knowledge of
language, domain, etc.
 “Between the two of us, we knew it or could figure it out”
 Apprenticeship
 Defect prevention always more efficient than defect removal
Vending Machine Program:
Responsibility Assignment
UI
Mary
Machine
Maintenance
Sue
Buy Drink
Joe
Data Structures
Charlie
Pair Rotation
UI
Buy Drink
Mary
Joe
Mach Maint.
Data Struct.
Sue
Charlie
Task
Owner
Partner
UI for ‘Buy Drink’
Mary
Joe
UI for ‘Add Inventory’
Mary
Sue
UI for ‘Add Recipe’
Mary
Sue
Input Coins/Return
Coins
Joe
Mary
Select Drink
Joe
Charlie
Ingredient Data
Structure
Charlie
Sue
Recipe Data Structure
Charlie
Sue
Add Ingredients
Sue
Charlie
Customer Analysis
Sue
Mary
Expected Benefits of PairProgramming
 Higher product quality
 Improved cycle time
 Increased programmer satisfaction
 Enhanced learning
 Pair rotation
 Ease staff training and transition
 Knowledge management/Reduced product risk
 Enhanced team building
The Benefits
of Pair Programming
Robert Kessler
School of Computing
University of Utah
Special thanks to
Laurie Williams
North Carolina State
University
What Is Pair Programming?
"Pair programming is a simple, straightforward
concept. Two programmers work side-by-side at
one computer, continuously collaborating on the
same design, algorithm, code, and test. It allows
two people to produce a higher quality of code than
that produced by the summation of their solitary
efforts."
This Is Pair Programming
This is NOT Pair Programming
Pair Programming Has Been Around
For a LONG TIME!
1945
...
1953 …
1997
1998
1999
2000
2001
John von Neumann, recognized his own
inadequacies and continuously asked others to
review his work.
Fred Brooks and many others are pair
programming, though they don’t know there is a
name for it.
2002
Does Pair Programming Really
Work?
Empirical study by Laurie Williams at the
university of Utah
 Practice: Summer 1999

– 20 students (sophomore/junior)
» All worked collaboratively
– Generated more anecdotal/qualitative evidence

Solo vs. pair: Fall 1999
– 41 students (junior/senior)
» 28 worked collaboratively
» 13 worked individually
– Software development process was controlled
» The only experimental variable: pair-programming
– Quantitative: time, quality, enjoyment, confidence
Findings #1 - Quality
Post Development Test Cases Passed
100.0%
90.0%
80.0%
70.0%
60.0%
50.0%
40.0%
30.0%
20.0%
10.0%
0.0%
Individuals
Collaborators
Program 1
Program 2
Program 3
Program 4
Findings #2 - Time
Elapsed Time
120.0%
100.0%
80.0%
60.0%
40.0%
20.0%
0.0%
Program 1
Program 2
One Individual
One Collaborator
Program 3
Findings #3 and #4 – Enjoyment and
Confidence
Enjoy the Work More Because of Pair
Programming
100%
80%
60%
40%
20%
0%
PROF
SUM1
SUM2
SUM3
Agree
FALL1
FALL2
More Confident in our Work When PairProgramming
FALL3
Disagree
100%
80%
60%
40%
20%
0%
PROF
SUM1
SUM2
SUM3
Agree
FALL1
Disagree
FALL2
FALL3
How Does This Work?

Pair-Pressure
–
–
–
–

Keep each other on task and focused
Don’t want to let partner down
“Embarrassed” to not follow the prescribed process
Parkinson’s law “work expands to fill all available time.”
Pair-Think
– Distributed cognition: “searching through larger spaces of alternatives”
» Have shared goals and plans
» Bring different prior experiences to the task
» Different access to task relevant information
» Must negotiate a common shared of action

Pair-Relaying
– Each, in turn, contributes to the best of their knowledge and ability
– Then, sit back and think while their partner fights on
How Does This Work (Part Two)?

Pair-Reviews
– Continuous design and code reviews
– Ultimate in defect removal efficiency
– Removes programmers distaste for reviews
» 80% of all (solo) programmers don’t do them regularly or at all

Debug by describing
– Tell it to the Furby

Pair-Learning
– Continuous reviews  learn from partners techniques, knowledge of
language, domain, etc.
– “Between the two of us, we knew it or could figure it out”
– Apprenticeship
– Defect prevention always more efficient than defect removal
Research Findings to Date - 1

Strong anecdotal evidence from industry
– “We can produce near defect-free code in less than half the time.”

Empirical study
– Pairs produced higher quality code
» 15% less defects (difference statistically significant)
» Observed – pairs produced smaller (LOC) programs
– Pairs completed their tasks in about half the time
» 58% of elapsed time (difference NOT statistically significant)
– Most programmers reluctantly embark on pair programming
» Pairs enjoy their work more (92%)
» Pairs feel more confident in their work products (96%)
Research Findings - 2

Several educational studies underway
– University of California, Santa Cruz; North Carolina State
University
– What about pair learning?
» Anecdotal says that it works well
– What are the long-term issues?
» If you learn as a pair, can you work as a solo?

Distributed pair programming studies underway
– North Carolina State University; University of North CarolinaChapel Hill
– Early results: distributed pair programming is viable
– My experience:
» Need to meet and know your pair
» Need a good tool like VNC and telephone
» Video not important
Issues: Workplace Layout
Bad
Better
Best
Issues: Partner Picking Principles
Expert paired with an Expert
Expert paired with a Novice
Novices paired together
Professional Driver Problem
Culture
Issues: Pair Rotation

Ease staff training and transition

Knowledge management/Reduced product risk

Enhanced team building
Issues: Process

Used in eXtreme Programming

Used in the Collaborative Software Process

Pair programming can be added to any process
Expected Benefits of Pair
Programming

Higher product quality

Improved cycle time

Enhanced learning

Pair rotation
– Ease staff training and transition
– Knowledge management/reduced product risk
– Enhanced team building

Increased programmer satisfaction
More Information

Bob Kessler
801-581-4653
kessler@cs.utah.edu

Laurie Williams
919-513-4151
williams@csc.ncsu.edu

http://pairprogramming.com
http://collaboration.csc.ncsu.edu/laurie
