Pair Programming

About me
ศิริวัฑฒ์ จิตต์หรรษา
Siriwat Jithunsa
siriwatj@gmail.com
Thomson Reuters

Objective
To give an overview about Pair Programming and its benefits which could make you curious and may want to try in your team.
To share and discuss about challenges and tips on doing pair programming.

Agenda
History
The Mechanics of Pairing
Some researches
Benefits
Why it works?
Pair Programming Patterns
Challenges
Tips
Discussion / Q&A

Xtreme Programming advocates pair programming on all production code .

Pair Programming History
Larry Constantine (1995) -
Called it " Dynamic Duo " development
Nissim Hadar (1996) -
I was leading a team of 4 programmers working on a flight simulator in 1996. Each programmer was assigned a separate aircraft system.
The programmers came to me and told me that, as they were always helping each other (this was FORTRAN on a weird system...), they wanted to work in pairs on each system.
This seemed inefficient to me at the beginning, but the big improvement came when the weaker programmers improved within a short time and there were fewer bugs in the fixed time we had for the project.

The Mechanics Of Pairing

Pair Programming Chair No, Thanks.

Two developers work on the same machine. Both have keyboard and mouse.
At any given time one is driver and the other navigator.
The driver codes, the navigator is reading, checking, spell-checking and sanity testing the code, whilst thinking through problems and where to go next. Real-time peer review.

The roles switch either every hour, or whenever really.
~ 4-6 hours a day

Effects of pair programming at the development team level: an experiment
Had 29% lower project productivity for the first three or four use cases.
The inefficiency was probably caused by:
the learning time
involved in getting familiar with new people and the pair programming practice.
Later teams spent 5% less effort than the Solo Programming teams for implementing the use cases.
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=1541842

Effects of pair programming at the development team level: an experiment
Code contained 8% less defects per use case
In the end of the project they delivered systems with a lower number of defects per use case.
Had slightly better design quality based on the method size and complexity metric

Martin Fowler said …
When people say that Pair Programming reduces productivity, I answer " that would be true if the most time consuming part of programming was typing "

Benefits
Good for learning and training
Deeper understanding of why , how and what was done
Better Quality
Fewer bugs
Instant validation of ideas
Adherence to team conventions
Increased productivity
Fewer interruptions - better focus
pushing each other and motivating to achieve best results
Less procrastination and wasting of time
Improved morale
Greater confidence that their work is correct.
Better discipline and time management
Less likely to skip writing unit tests, spend time web-surfing or on personal email

Industry Metrics
Laurie Williams of the University of Utah in Salt Lake City has shown that paired programmers are only 15% slower than two independent individual programmers, but produce 15% fewer bugs (N.B.: The original study showed that 'error-free' code went from 70 % to 85 %; it may be more intuitive to call this a 50 % decrease of errors, from 30 % to 15 % ). Since testing and debugging are often many times more costly than initial programming, this is an impressive result.
http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF

Why it works?
Two people have differing specialities, these skills are transferred.
“ everybody has some expertise, some knowledge or ideas that are worth sharing .”
Ad-hoc training occurs as one person shows the other some tricks and techniques, nice workarounds, etc.
Both developers are fully aware of the code, how it works, and why it was done that way.

Why it works?
It's less likely to contain bugs and hacks and things that cause maintenance problems later.
Chances are the code is better than one developer working alone, as there was somebody watching.
It is impossible to ignore the reviewer when he or she is sitting right next to you.

Why it works?
It gets developers talking and communicating ideas in the common language of code.
The code got written quicker and didn't require revisiting. And when it did need to change, more than one person was familiar with the code.
Continuous Code Review

Pair Programming Patterns
Driver-Navigator
Mouse-Keyboard
Ping-pong

Driver-Navigator
Driver
Is the person typing the code
Navigator
Reviews what the driver is writing
Roles should switch frequently
~1 hour at a time in each role

Mouse-Keyboard
Driver:
Uses keyboard
Navigator:
Uses mouse
Benefits:
Makes sure everybody is contributing/engaged

Ping-pong
Driver:
Writes code
Navigator:
Writes tests
Benefits:
Another developer evaluates functionality

Challenges
To get the buy-in on doing pair programming from Management
Understand the benefits and cost
Everyone has to WANT to pair.
they all at least need to be curious enough about it to give it a genuine shot - attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work.
Environment
The developers need to be side by side, the same distance from the monitor (which needs to be large).
You might need more chairs.
Personal Preferences
Hygiene can be a serious problem.
Timing

Tips
Agree on one tiny goal at a time
Using Unit Tests
Sync up frequently (Communicate, Ask & Listen, Compromise or take your stand)
Make sure you both know what the other one is working on and thinking
Switch roles often (at least once an hour)
If you’re stuck or frustrated, try switching roles

Tips
TDD - Write a unit test first. This will help you and your partner to agree on the goals.
Switch partners when you start a new iteration
Schedule breaks if necessary
Decide to take a 5 minute coffee break if things are getting tense or you need a second to think
Take a moment to celebrate
Getting feedbacks from your team

Q: Expert & Junior
Possible Issues:
A boring lecture
A one-man show game - the expert monopolizes the keyboard and never let the other drive it.
Solutions:
Communicate.
Junior should ask wisely and Expert should answer wisely.
Record Your Communication In The Code

Record Your Communication In The Code
If the junior can't understand some bits of the code
And then asks on it
The expert notices that he failed to make the code clear at every point
The pair tries "together" to refactor the bits into a new method with an explanatory name
remember that when you use comments as the last resort, the code quality will improve much more
So that next time other pairs see the bits, there be no need to ask/explain/explore whatever but to learn fast.

Jeff Atwood – Coding Horror “ When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. ”

Resources
Web Sites:
Pair Programming
I Love Pair-Programming
Pair Programming vs. Code Reviews
Pair programming. What researches say on the costs and benefits of the practice.
Book
Pair Programming Illuminated

Thank You
& Special Thanks to my team for real-world input, experience, and support

Discussion / Q&A

Pair Programming

by siriwatj on May 25, 2009

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 8

Statistics

Pair Programming Presentation Transcript