Pair Programming Questions
Pair Programming QuestionsQuestions and concerns about PairProgramming:
Logistical concerns
Q: I hear that it's not uncommon for people to switch pairs several times a day. [In fact, that's preferred. I hear many different questions that arise from the mistaken assumption that the pairs are static and unchanging.] How is that done? For example, if someone needs to work with me for a while, what does my old partner do? Pair with the old partner of the person I'm now paired with? Find someone else? Work alone on something? Or suppose my pair needs to go grab someone to work with. I've noticed in practice that TriProgramming doesn't work too well, two of the people tend to focus on each other leading to a "third wheel" effect. So if my pair grabs someone to consult, should one of us in my pair go do something else or find a new partner? -- NathanUrban
A: The "grab" should be consensual with the old partner. Ask the old partner if it's okay for you to pair with someone else. Not only is this courteous, it gives the old partner a chance to point out that maybe you shouldn't; maybe what you're working on is more important than this new task. There's a good chance that the old partner will have something else to work on; perhaps a SpikeSolution, or s/he can take a break, then find somebody else to help.
Power struggles
Q: Do pair programmers ever feel tempted to "cave" on something when it's causing a lot of friction with their partner?
A: If there's a lot of friction between partners, then the pair seems disfunctional in some way. Perhaps pairing between those two should be minimized. PairProgramming should flow.
Non-Programming Tasks
Q: How do you handle things like reading e-mail, news, and WikiWeb? Do people have individual computers too? Or do people just do those things while at home?
A1: In BookXp, there is a central, open space with the fast development machines where PairProgramming occurs, and there are semi-private or private cubbyholes on the perimeter with slower machines. One would assume that these could be assigned to individuals as offices or cubicles with personal/AdminisTrivia? software. No development should occur on these machines.
A2: Another Answer: Maybe that's one reason that PairProgramming is so much more productive! :-)
A3: Pairs can work on separate machines, using a remote control product such as MicroSoft NetMeeting, allowing either pair to research while still observing coding being performed by the other pair.
Domination in pair
Q: How do you avoid the situation of the more dominant member of the pair taking over and the other sitting watching and not contributing?
A: If the dominant member takes over the keyboard and won't listen to the other team member's advice, get up and walk away. (If they code away, ignoring your comments, then you're not doing PairProgramming, so get up and walk away, making it obvious that they're hacking away alone.)
If the dominant member does not have the keyboard, but micro-manages (tells you character-by-character what to type), there are several things you can do:
Unable to dominate in pair
Q: Two developers have different solutions but it is almost impossible to decide whether the first or the second is better. Obviously every developer is convinced that his/her solution is the best to develop to achieve the task goal in a better manner. At a given point somebody must decide on a solution (often the group responsible) and so you will have, at least, one unhappy developer (if not two). What's the solution?
A1: If neither can convince the other in 5 minutes, flip a coin to decide, try it out and see if it works. If it doesn't seem to work, then either modify the chosen solution or back-out the changes and try the other solution. Even if neither works, you've tried two solutions and gained some experience in the time you might have wasted just arguing and creating bad feelings, and you'll be free to brainstorm up some new ideas or get advice from others.
A2: Present the problem to a third party and get their opinion. If two smart people are having an intractable argument, then the issue is probably significant, and is worth another opinion
A waste of resources?
WardAndKent are outspoken proponents of this style of development. The most often asked question: "Won't my management think we are wasting resources?" can be answered by explaining the many productivity improvement opportunities pair programming creates. A better answer might be to suggest more faith in management's ability to recognize productivity when they see it. --WardCunningham
PairProgramming vs CodeReviews
Q: I am trying to get PairProgramming introduced in my workplace, and mentioned the research that LaurieWilliams has done on the benefits of pairing. Our QA manager was interested, but asked if there was any research done comparing PairProgramming with solo programming followed by a CodeReview (she is a big fan of reviews and inspections). I am sure that PP would be more effective, but does anyone have any hard data?
A: Have a look at http://www.pairprogramming.com - they have some good data. - LenWeincier
Q: Is there experience on how PairProgramming works with people with AccessibilityIssues?? What are the affects of AccessibilityIssues? between a pair where one has them and the other one doesn't?
Who picks the pairs?
Q: This is good stuff, but I'm wondering about two issues (which may be discussed elsewhere, but I haven't found them). The first is, how does the pairing process work, what happens if two people consider themselves incompatible? It strikes me that if the individual developers are entirely self-organizing it could produce negative effects. Also, is there a bun-fight over particular interesting tasks? I can imagine in a well-factored system there mightn't be a big variance between appealing and dull tasks, but with a large legacy system there is bound to be. --EoinCavanagh
A: In XP, team members sign up for tasks. Tasks are never assigned. Some days there's a rush to sign up for some particular thing, but I've never seen it come to blows. Since XP developers are completely cross-trained, they're generally ready to sign up for anything and the signup process is stress-free. Once in a while I might "encourage" someone to sign up for a specific area, or more rarely discourage.
I've met one developer with whom no one could pair. He seemed to be an anomaly. Within C3, all the teams work pretty well. Once in a while I have to whack someone with the rolled-up newspaper to get them to behave. Folks develop favorite partners, and we just quietly encourage them to shop around. We've seen no negative effects. -- RonJeffries
Q: Taking the last answer I'd like to ask how should a company handle a programmer who, for some reason or other, is not fit for PairProgramming? Is this person not fit for the company or are there other tasks for him/her?
Pairing in other contexts
Q: If pairing works for programming, does it also work for other things such as documentation, high-level design, software evaluation, project managing, etc.? When is pairing not advisable?
A(1): not entirely related, but with the house cleaners that I use, when they pair it is always a much better job. Solo ends up being sloppy, much like my code (at work... not at home... weird).
A(2): Yes, it works for many other endeavors, but be aware that there's a difference between PairProgramming (the XP practice), and programming with someone else (the simple human operation). Much of PairProgramming's power comes from its context - the fact that the pair is working on an EngineeringTask, that they are working on an established code base, etc. Other human endeavors don't have the same parameters, which makes pairing much less effective.
It depends on the amount of personal creativity required. You couldn't Pair Paint [but see below], for example, though two artists can certainly bounce ideas off each other, and one might provide an underlying sketch that the other paints over, but the artists couldn't take turns painting. So, the more individualistic the project (and the result), the less PairProgramming is useful. Which makes sense.
Also, programming benefits from an economy of scale: any typical software project will have a group of programmers, but there's just no point in hiring two project managers. So, project management or configuration management wouldn't benefit from pair programming (in most cases) because there's simply not enough of that sort of work to do.
A(3): I think you could pair paint just fine. When I pair program, there aren't 4 hands on the keyboard. I reckon if two artists had similar goals for a piece of work, there should be no problem with them taking turns to work on it, with one person always keeping an eye on the general direction, helping to catch problems early and so on. (I think the biggest problem could be personality/ego issues, but then programmers aren't generally known for their modesty on technical issues either ;-) [CorelPainter allows people to collaborate on a digital painting over a network.]
Similarly, I think pair management is well worth trying; it just takes a slightly different approach. I have a project where a colleague and I essentially do pair-everything, which for us includes coding, project management, database design and maintenance, and longer-term planning. It works really well. I think you have to make sure that the other folk on your team don't feel like they're being led in two different directions, but in a way that just forces you to be very open & clear on where the project is heading (and that, I suspect, can't be a bad thing). -- KevinMcConnell
See also PairProgrammingDoubts, PairProgrammingMisconceptions, HowToPissOffYourPair, MarkYourTerritory, IsPairProgrammingMandatory, XpWithoutPairProgramming, PairProgrammingBenefits, PairProgrammingDeniers
EditText of this page
(last edited July 7, 2013)
or FindPage with title or text search