Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair
works together at a single workstation. They share the keyboard, mouse, and monitor.
The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are
locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both
programmers are equally engaged in writing the code, and neither can claim authorship.
Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might
last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.
During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The
programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half
will be working on other's tasks.
Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code
walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.
Even though every task is the responsibility of an individual programmer, many other programmers will have worked on
that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single
programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to
work in any module in the system.
Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to
get you to see a different point of view.
When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody
on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team
You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help
you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes.
However, you can negotiate schedule.
Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any
formal manner. The coach or another team member or the team as a whole may notice that certain team members have
adopted pathological pairing activities and may intervene.
When you get tired of your current partner.
When you think your current partner is too tired or distracted to help.
When the two of you get stuck on a concept.
Or generally whenever you feel like it.
Yes, of course. You just can't check in production code that you've written on your own.
Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or
distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer
should have a private place to go.
When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are
not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing
session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise
refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.
Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the
value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It
is always much easier to write a module the second time, and the result is always better. So, if you program alone,
think of the code as a rough draft that you will throw away and rewrite with your pair partner.
Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report
that they are more productive than when they worked alone.
This anecdotal evidence is backed up by some research studies. Some of those studies can be found at www.pairprogramming.com.
One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or
defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down
dead ends and being blocked on ideas.
One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in
half. It may be that pairing allows the two to think twice as quickly.
Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths,
telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get
along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are
over the top. How do you pair with such a person?
Grin and bear it, it'll only last for a couple of hours.
Bring breath mints.
Leave deodorant or gelucel on his desk.
Write anonymous letters to the offender.
Disconnect the phone.
Complain to your boss.
But, by far, the best advice is to tell your pair partner outright what bothers you.
Left handed vs. right handed mouse users.
Some people need special keyboards to control RSI or OOS.
Some people use Dvorak keyboards.
Some people need to special screens to be able to see.
Some people prefer a trackball to a mouse.
Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors,
etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.
In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations
sitting next to each other, connected with NetMeeting or some other kind of collaboration software.
At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into
sub-projects that can be done separately at each geographic location. That way the programmers at each location can
pair with each other and won't have to interact as much with the remote programmers.
Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or
other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local
pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of
person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication
Perhaps you are outrunning him. Try to go a little slower and get him engaged.
Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he
has a chance to try as many of his ideas as you get to try of yours.
Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is
dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do
about it. Perhaps the team will ask him to write configuration scripts or something.
Gently ask him if you can drive for a while.
Gently ask him to describe what he is doing.
Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the
team will have to figure out what to do.
Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic
notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent
and usage. It will take time, but the situation will improve. Do not give up!
Some people come in early; some people stay late. How can you find pair partners if everybody has a different working
Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most
personal schedules allow this.
Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change
their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the
evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.
Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes
available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that
he is unfamiliar with.
Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the
opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should
break them up by suggesting that they pair with others.
The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new
members of the team. Newbies should pair most often with team members with more seniority.