XP/xp/guidances/guidelines/pair_programming.xmi - epf/org.eclipse.epf.libraries - Git at Google

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