pair programming: why have two do the work of one
DESCRIPTION
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. - PowerPoint PPT PresentationTRANSCRIPT
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 199941 Students (Junior/Senior)
28 Worked Collaboratively13 Worked Individually
Software development process was controlledThe only experimental variable: pair-programming
Quantitative: Time, Quality, Enjoyment, Confidence
Post Development Test Cases Passed
0.0%10.0%20.0%30.0%40.0%50.0%60.0%70.0%80.0%90.0%
100.0%
Program 1 Program 2 Program 3 Program 4
Individuals
Collaborators
Boxplot of Program Quality
WORKING
IndividualCollaborative
DEFECTS
120
100
80
60
40
20
0
Elapsed Time
0.0%
20.0%
40.0%
60.0%
80.0%
100.0%
120.0%
Program 1 Program 2 Program 3
One Individual One Collaborator
Boxplot of Student Time
WORKING
IndividualCollaborative
TIME
1800
1600
1400
1200
1000
800
600
400
200
0
Collaboration by Phase
0%10%20%30%40%50%60%70%80%90%
100%
Collaborative Individual
ENJOY the work more because of Pair Programming
0%
20%
40%
60%
80%
100%
PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3
Agree Disagree
More Confident in our Work When Pair Programming
0%
20%
40%
60%
80%
100%
PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3
Agree Disagree
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
Lines of code per hour
0
5
10
15
20
25
Non-paircolocated
P aircolocated
Non-pairdistributed
P airdistributed
Quality
Grades
0
20
40
60
80
100
120
Non-paircolocated
Pair colocated Non-pairdistributed
Pair distributed
Satisfaction with Working Arrangement
Verygood
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
Verygood
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
Buy Drink
Joe
Data Structures
Charlie
Machine Maintenance
Sue
Pair RotationTask 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
UI
Mary
Buy Drink
Joe
Mach Maint.
Sue
Data Struct.
Charlie
Expected Benefits of Pair-Programming
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 Benefitsof 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 2002
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.
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
Post Development Test Cases Passed
0.0%10.0%20.0%30.0%40.0%50.0%60.0%70.0%80.0%90.0%
100.0%
Program 1 Program 2 Program 3 Program 4
Individuals
Collaborators
Findings #1 - Quality
Elapsed Time
0.0%
20.0%
40.0%
60.0%
80.0%
100.0%
120.0%
Program 1 Program 2 Program 3
One Individual One Collaborator
Findings #2 - Time
Enjoy the Work More Because of Pair Programming
0%
20%
40%
60%
80%
100%
PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3
Agree Disagree
More Confident in our Work When Pair-Programming
0%
20%
40%
60%
80%
100%
PROF SUM1 SUM2 SUM3 FALL1 FALL2 FALL3
Agree Disagree
Findings #3 and #4 – Enjoyment and Confidence
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 Carolina-
Chapel 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 ExpertExpert 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
Laurie [email protected]
http://pairprogramming.com http://collaboration.csc.ncsu.edu/laurie