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

Bob Kessler801-581-4653kessler@cs.utah.edu

Laurie Williams919-513-4151williams@csc.ncsu.edu

http://pairprogramming.com http://collaboration.csc.ncsu.edu/laurie