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:

"It's distracting. It interrupts my flow and concentration."
"It's wasteful. We might not spend twice as long, but we'll certainly spend longer!"
- No, it isn't. You will spend slightly longer, but you get that time back (possibly with dividends)
- This is a strong claim, and it might need more data than just the one research projected I have seen (ExtremeProgrammingResearch). So, get measuring. See PairProgrammingEconomics
"The other guy thinks too quickly, I cannot follow his thinking."
- Thinking that you can't follow is not the kind you want on your project. Get him to explain what he's doing.
"The other guy thinks too slowly, I don't want to be a teacher all day long!"
- If you are a good enough teacher, he will speed up. And anyway, why are you staying in the same pair all day?
"The other guy t-y-p-e-s s-o s-l-o-w-l-y, I get impatient!!!"
- Patience is a virtue. Learn it. Typing competently is also a virtue. Learn it. There are many factors that influence your effectiveness as a programmer: Typing speed isn't the most important thing. Of course it isn't the most important thing, but that doesn't make it trivial. Professionals use professional tools for a reason. If you can't type competently, or (for another example) if you use a hopelessly under-powered text editor as your "programmers editor", it is somewhat analogous to a professional mechanic using the worst quality dime-store handtools. It is possible to get the job done this way, but that just isn't the point. If you can't take the time to make yourself a competent typist, it reflects badly on your capabilities and attitude to your work. This is a tool you use every day! When is the last time you heard a carpenter say "well, I don't really have to know how to hammer efficiently." BackToBasics
"One of the reasons I wanted to be a programmer, is so I don't have to deal with people all the time!"
- Get a job at a non-XP shop
- The variations upon this theme seems to be too plentiful, especially a priori, so you would exclude quite a few programmers to many. Probably. Why would I care?
- If you don't like dealing with people, you have worse problems than PairProgramming.
- The previous comment is unfair and unhelpful. Please don't tar everyone who disagrees with CommunalProgramming? as simple social misfits with chips on shoulders. It does nothing to help your cause; it only makes you look like a Grade A Asshole.
- That comment was in response to the programmer who doesn't want to deal with people, not to everybody who dislikes PairProgramming. And, c'mon, if you're a programmer who doesn't like dealing with other programmers while programming, you probably do have serious social interaction problems. It's not like they're being asked to take ballroom dancing classes with their girlfriends. They're being asked to do something they know how to do, and presumably enjoy doing, with somebody who else who presumably shares those same passions.
- He said he doesn't like to deal with people all the time which is not the same as saying that he doesn't like to deal with people at all. Some people might have a preference for being able to focus in silence and the fact that they do things differently than you doesn't justify trying to stigmatize them with accusations of serious psychological problems.
"The other guy smells!"
- Get him to get a job at a non-XP shop
"The guy on the next team has such a irritating voice, I can't concentrate."
- Sit somewhere else. As I write this, the two most irritating voices in the office are PairProgramming and arguing loudly. I don't have a choice where I sit. I might just go postal instead.
- This is always a problem in open-plan offices. I get driven bonkers trying to think through the mobile phones ringing with "cool" tunes. Solve the problem of "people being disturbed by noise" rather than the specific one. -- KatieLucas
I keep my own schedule. Working on a time clock would remove one of the reasons I like programming.
- I'd say the problem is not per se the clock - you just need to find a partner who wants to run the same sort of schedule, surely? -- KatieLucas.
Why should I play secretary and type in the code as it is dictated to me?
- You shouldn't, that's not PairProgramming. If your partner is failing to think abstractly and is instead dictating code to you, hand them the keyboard.
What should I do while the other person is typing in code?
- This is addressed at the top of PairProgramming: "Each member performs the action the other is not currently doing". If they're typing in a UnitTest, you should guide them based on how you see the implementation; if they're typing in the implementation, you should be guiding them based on how the code will be tested and used.
I want to code, not watch other people do it.
- If you accept that programmers need to be reviewing each other's code, then you need to accept the responsibility to do that activity some of the time. (If you don't accept the need for code review or collaboration, you have more fundamental differences to overcome than this objection.)

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:

If the programmers are in cubes, break the walls down.
If their desks are placed in such a way that makes pairing even slightly difficult, change the desks.
If pairs get funny looks because they are disturbing people on other projects, move everybody into a WarRoom.
If people are afraid to pair because they feel too much time pressure and have to focus on "their" tasks, lighten the load.
If people are reluctant to pair because performance reviews focus on "their" accomplishments, change the review system.
If people tend to spend days between checkins, make them check in at least daily, so that they have to collaborate with people working in the same areas. (suggest this become "make checkins quick and easy"?)
If people just don't talk much, give them opportunities (order lunch in, put the water cooler and snacks in the middle of the room, get beer delivered on Friday afternoons, take everybody out to a ball game, etc.)

CategoryPairProgramming