Pair Programming Doubts

I'm in a project involving PairProgramming. As per recommendation, the relative newbie is at his keyboard. The whole time, I've felt that I could work alone faster than the two of us are working together. Now I'm starting to wonder if the pair is holding my partner back. When I try and get him to come up with the next idea, silence fills the air.

Similar questions in PairProgrammingEconomics

How big is the task that you two are performing, and which part are you letting your partner perform (because you're not doing it right then)?


Of course this may depend on the ratio of experience - if one partner is much less experienced, he may lack confidence to express his ideas. Alternatively, if he's really inexperienced he may simply need more time on his own to come up with the ideas.

In that case it may well be slowing you down - but think of the time you spend as an investment in tutoring. -- BurkhardKloss


Ideally, PairProgrammingIsDoneByPeers. Each knows something the other doesn't, each has characteristics that the other does not have, but they think of the other as an equal partner. When a very senior person pairs with a beginner, the senior person is tutoring the beginner. This can be good, but it is not a typical example of pair programming. -- RalphJohnson


PairProgramming is about trust. You don't trust that person because you know or think they are junior to you. I agree with RalphJohnson that the pairs should be composed of peers. However, there is benefit to pairing up unequal pairs: we call that mentoring. It has an entirely different purpose. -- RonPerrella

I think there's an important distinction here between a person's experience and ability. Working with someone who is inexperienced but smart is productive, but other people just don't have the raw ability to keep up. I suppose it's a bit like ConvoySpeed. One shop I know of had to let someone go because he was dragging the team down - he'd been hired by management without proper selection process - but they've had great success with a bunch of new graduates. -- SteveFreeman


PairProgrammingObjections:

Some of these are based upon my own sentiments, while others are just things I found to be plausible. Any takers? -- JohannesBrodwall

They may be based on your sentiments: are they based on your experience? No offence meant, but responses to PP tend to be like responses to NabokovsLolita. Everyone knows PP doesn't work, right, except people who've tried it. So, too everyone knows Lolita is pornographic, right, except people who've read it.''

Indeed. The sentiments that are mine are based upon (a little bit of) real experience. The others are objections I have heard when I've been discussing PairProgramming with peers. I feel that these doubts are important to address in any case, since they might be strong hurdles to overcome in order to get started with PairProgramming. Not everyone responds well to "let's just try it". Thanks for the input.

FearIsTheMindKiller


I have been attempting to get our company's team of 10 (java) programmers to look at more efficient and effective ways to develop. I would describe the method used to date as WaterFall. Over the past 6 months I've been steered toward XP and PP ideas primarily through contact with wiki. I recently carried out a short informal survey of their thoughts and 6 out of the 10 in the team responded in a way similar to the list above from JohannesBrodwall. One additional reason stated by most (even some of the silent) are the many references in XP and PP to Ideally and as the team all know "the ideal is just that, ideal, not real or practical." One other comment surfaces frequently and that is working with a peer may not be feasible as the small team just doesn't break up into neat peer = peer teams. Finally 'senior management' is not inclined to use the company's resources on a GAMBLE that mentor to newbie pairs will someday pay dividends. They are not willing to take the risk without substantial firsthand knowledge of the method's effectiveness; firsthand refers to the fact that no one on the team has any XP experience. So what would the combined wisdom (I mean this sincerely) of wiki's XP community suggest I do? Give up, change jobs or have I missed something very basic? -- DaveSteffe


I guess my thoughts and questions weren't helpful. Let me try again.

I'm concerned about the notion that the team doesn't break down into "neat peer = peer teams". No two of us are identical, but many of us can work together. Say more, please about what is keeping you apart.

Can you say more about why "senior management" doesn't want to put "mentor" with "newbie"? What would they rather do, and what's your guess at why getting the newbies up to speed isn't important to management?

Since "ideal" is something one might strive for, please say more about why the team resists ideas because they express an ideal.

Did someone really say "They are not willing to take the risk without substantial firsthand knowledge of the method's effectiveness"? Surely they know you can't get firsthand knowledge without trying things. What, in your estimation as the guy on the spot, lies behind this apparent contradiction?

It seems to me that there must be some intense emotions behind all of the stuff above, since there are apparent contradictions on the surface of what you have observed. Therefore I ask, what can you tell us about what must really be going on in the minds of the folks?

-- RonJeffries

What goes on in their minds? Frankly, I have given up trying to understand that and instead embraced the recommendation "if you can't change your company, change your company". As opposed to any other wacky idea I've seen here, PairProgramming always seems to arouse a healthy (?) skepticism. With BigDesignUpFront it's "of course, we must do that!". With CodeUnitTestFirst, the reply is usually "that sounds like a good idea, but I don't think I'm up to it". With PairProgramming, the reply is "that sounds like a bad idea. Let's do something else". Weird. -- JohannesBrodwall

I started explaining my thoughts about why people object to mentoring because they actually object to skilled staff here, but it got long so it's on SoftwareLabourers now. Basically, for a misguided set of reasons companies get used to software being made by unskilled workers. They (sort of) like it that way (politically... practically, they still want perfect code) and hence will resist any attempts to train up staff in any meaningful way. -- KatieLucas


One additional reason stated by all ... are the constant references in XP and PP to "Ideally".

One more thing. Where are all these "constant references"?

>> I was listing the responses made by the developers, not my personal list. Having said that I see one example near the top of this page "Ideally, pair programming is done by peers."

Saying "ideally pair programming is done by peers" <is this ideal? I think not> is very different from saying "ideally we will use pair programming," or "ideally pair programming will be effective" ...

The point is - and it is one that DonWells makes particularly well - is that there's a difference in the interaction when it's two equals working together vs a mentor/newbie. Real pairing is a cooperation between peers and there's much more of a mind meld. For good mentor pairing, the mentor needs to slow down, and probably to encourage the mentee to do most of the typing. What was behind the is this ideal question?


I snuck some pair programming into a project where I was a TechnicalLead at a notorious CubeFarm. Because of the cubical setup, it was impractical to try to get two programmers on the team to sit together all the time. However, I could (and did) take advantage of the constant stream of break and vacation schedules to ask a programmer who had worked on a particular module to spend time getting another programmer up to speed on the module so the other could take over while the first was out of town. Invariably the "visiting" programmer had suggestions that improved the code.


PairProgramming is the area where XP starts looking like a WackoReligiousCult?. I have done plenty of PairProgramming. When the situation warrants it. But not as a way of life.

So far, all I see is that the Pro-PP argument is based on this sort of testimonial-based propagandizing salesmanship.

The argument is that, with two people who "believe in PairProgramming", enjoy it, and are good at it, their productivity together will exceed that of the sum of their productivity working alone.

Isn't this just self-evident?

But I don't understand. Why stop at PairProgramming? Why not TrioProgramming?? QuartetProgramming?? QuintetProgramming?? ChoirProgramming?? Because humans work well in pairs. XP is not concerned with finding a theoretical ideal number of programming participants; it's been shown in real projects to have practical benefits.

It looks like what you don't understand is networking theory :)

I mean, come on now. This is the Connectivity Age. Surely we can come up with a way to let all of the cooks join together in one big VirtualKitchen? and create a CrockPotEngineeringMasterpiece?? What is this two-chairs-at-a-desk/monitor bullshit? Have some IMAGINATION!

But anyway... In the end, we all pick what we do. The lovers of PP will stick to it like BBQ on ribs, and the rest of us PairProgrammingDeniers will avoid it like the plaque. And all will be right with the world.

--AbrasiveFungalAgent?

That last paragraph especially is really unfair to the PairProgramming aficianados, and I'm tempted to DeleteInsults here. It suggests that XP advocates will invariably follow XP blindly, and not only do I see no justification for this attitude, it runs against the XP practice of TheyreJustRules. -- BrentNewhall

To me, it's mainly a quality of work environment issue. I do my best programming work alone. Maintaining the constant interface between two separate human minds is just too much overhead. But I do acknowledge that "flow" can happen with another person. To the people for whom PairProgramming works: all power to you. It's just not my thing.


To those of you who are studying computer science, and hoping this will relieve you from the pain of developing social skills: you won't need social skills as much as the marketing guy, but you're going to need some - right from Day 1, The Interview.

Social skills aren't my concern; I'm perfectly comfortable discussing technical matters with my coworkers. Regarding PairProgramming, I wonder whether I can do a first-rate job of programming and talking concurrently. Those tasks involve different ways of thinking, and conversation might interfere with the programming flow.

I don't see how PairProgramming requires simultaneous programming and talking. It's more like alternating phases of programming and talking. In my (admittedly very limited) PairProgramming experiences, most of the actual coding is done in relative silence, until a participant hits an issue, and then the talking begins. -- BrentNewhall


Another reason pair programming does not take twice as long for the same code is the social dynamic of it. The addition of another person at the keyboard is another person whos energy and concentration are directed at the goal of creating solutions. When working in a pairing situation there is not time to stop and pick your nose or check out the latest score in the ball game. You have right next to you, in your face, and if your attention or energy ever flags it is easy to "borrow" those of your partner to get you going. Both people in a pair end up working harder than they might by themselves, for less mental strain.

From personal experience, I find it quite hard to keep up the concentration I see from dedicated solo programmers. With pair programming it is possible to keep up the same rate of work without needing to put so much mental effort into doing so.

People I have worked with feel more mentally drained from a pairing session than from even an intensive session of going solo (because the work the brain has been doing is greater?). With a good pair time flies and code flows from the fingertips, this is why pairing is often loved rather than just being thought of as a good idea.

And thus it is this synergistic flow created between two pair programmers that provides the excitement and the effusiveness you see on the faces of XPophiles, as they tell you how great XP is. This strange look in their eyes may also be the reason you are cautious of XP.

It is possible to view XP as a system that give pairs of programmers the support they need to do so. Without the other facets of XP, it is much harder to support the process of pair programming. It is harder use the other facets of XP without pairing.

In summary, the intuitive argument that two people doing the work of one will cost twice the man hours to complete is false. In the case of a good pairing, those two people will be working harder than normal, even in the case of a mediocre pairing.


Quoted from William Pietri:


CategoryPairProgramming

EditText of this page (last edited May 2, 2011) or FindPage with title or text search