| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.2.0" xmi:id="-nfbUMyTTqEbCp3HDn-NjOA" |
| name="pair_programming,3.85153041801319E-307" guid="-nfbUMyTTqEbCp3HDn-NjOA" changeDate="2006-11-09T19:44:32.495-0500" |
| version="1.0.0"> |
| <mainDescription><a id="XE_xp__pair_programming" name="XE_xp__pair_programming"></a><a id="XE_pair_programming__in_xp" name="XE_pair_programming__in_xp"></a> 
 |
| <h3>
 |
| Topics
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| <a href="#WhatIsPair">What is pair programming?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#WhyPair">Why Pair Program?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#FormingPairs">How Pairs Form</a>
 |
| </li>
 |
| <li>
 |
| <a href="#ChangingPairs">When to Change Partners</a>
 |
| </li>
 |
| <li>
 |
| <a href="#WorkingAlone">Can't I work alone?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Productivity">Doesn't this cut my productivity in half?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Hygiene">Hygiene and Etiquette Issues</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Disabilities">Disabilities and Physical Incompatibilities</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Distributed">Our Team is Geographically Distributed</a>
 |
| </li>
 |
| <li>
 |
| <a href="#BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
 |
| </li>
 |
| <li>
 |
| <a href="#NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Language">My Partner and I have different First Languages</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Schedule">How do we deal with different personal schedules?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#OddNumber">What if we have an odd number of programmers?</a>
 |
| </li>
 |
| <li>
 |
| <a href="#Pathologies">Pairing Pathologies</a>
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="WhatIsPair" name="WhatIsPair">What is pair programming?</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="WhyPair" name="WhyPair">Why Pair Program?</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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
 |
| member.
 |
| </p>
 |
| <h3>
 |
| <a id="FormingPairs" name="FormingPairs">How Pairs Form</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="ChangingPairs" name="ChangingPairs">When to Change Partners</a>
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| When you get tired of your current partner.
 |
| </li>
 |
| <li>
 |
| When you think your current partner is too tired or distracted to help.
 |
| </li>
 |
| <li>
 |
| When the two of you get stuck on a concept.
 |
| </li>
 |
| <li>
 |
| Lunchtime.
 |
| </li>
 |
| <li>
 |
| Quitting time.
 |
| </li>
 |
| <li>
 |
| Or generally whenever you feel like it.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="WorkingAlone" name="WorkingAlone">Can't I work alone?</a>
 |
| </h3>
 |
| <p>
 |
| Yes, of course. You just can't check in production code that you've written on your own.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="Productivity" name="Productivity">Doesn't this cut my productivity in half?</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| This anecdotal evidence is backed up by some research studies. Some of those studies can be found at <a href="http://www.pairprogramming.com" target="_blank">www.pairprogramming.com</a>.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="Hygiene" name="Hygiene">Hygiene and Etiquette Issues</a>
 |
| </h3>
 |
| <p>
 |
| 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?
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Grin and bear it, it'll only last for a couple of hours.
 |
| </li>
 |
| <li>
 |
| Bring breath mints.
 |
| </li>
 |
| <li>
 |
| Leave deodorant or gelucel on his desk.
 |
| </li>
 |
| <li>
 |
| Write anonymous letters to the offender.
 |
| </li>
 |
| <li>
 |
| Disconnect the phone.
 |
| </li>
 |
| <li>
 |
| Complain to your boss.
 |
| </li>
 |
| <li>
 |
| But, by far, the best advice is to tell your pair partner outright what bothers you.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="Disabilities" name="Disabilities">Disabilities and Physical Incompatibilities</a>
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| Left handed vs. right handed mouse users.
 |
| </li>
 |
| <li>
 |
| Some people need special keyboards to control RSI or OOS.
 |
| </li>
 |
| <li>
 |
| Some people use Dvorak keyboards.
 |
| </li>
 |
| <li>
 |
| Some people need to special screens to be able to see.
 |
| </li>
 |
| <li>
 |
| Some people prefer a trackball to a mouse.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="Distributed" name="Distributed">Our Team is Geographically Distributed</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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
 |
| channel.
 |
| </p>
 |
| <h3>
 |
| <a id="BossHog" name="BossHog">My Pair Partner Hogs the Keyboard and Ignores Me</a>
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| Perhaps you are outrunning him. Try to go a little slower and get him engaged.
 |
| </li>
 |
| <li>
 |
| Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="NoSolution" name="NoSolution">My Pair Partner and I Cannot Agree on a Solution</a>
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| Gently ask him if you can drive for a while.
 |
| </li>
 |
| <li>
 |
| Gently ask him to describe what he is doing.
 |
| </li>
 |
| <li>
 |
| Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| <a id="Language" name="Language">My Partner and I have different First Languages</a>
 |
| </h3>
 |
| <p>
 |
| 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!
 |
| </p>
 |
| <h3>
 |
| <a id="Schedule" name="Schedule">How do we deal with different personal schedules?</a>
 |
| </h3>
 |
| <p>
 |
| Some people come in early; some people stay late. How can you find pair partners if everybody has a different working
 |
| schedule?
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="OddNumber" name="OddNumber">What if we have an odd number of programmers?</a>
 |
| </h3>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <h3>
 |
| <a id="Pathologies" name="Pathologies">Pairing Pathologies</a>
 |
| </h3>
 |
| <ul>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| <li>
 |
| 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.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| <br />
 |
| <br />
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
