Fog Creek Software
Discussion Board




Pair Programming Experiences

I'm sure some of us have tried the Extreme Programming principle of Pair Programming, in which two developers work on the same piece of code at once.

For more, see this page: http://c2.com/cgi/wiki/wiki?PairProgramming

Have you ever Pair Programmed?  What was the experience like?

Brent P. Newhall
Friday, March 07, 2003

Perhaps I'm just a cynic, but the pair programming aspect of XP just seems ridiculous to me: To have two guys at a computer jockeying over who gets to play with the steering wheel just seems absurd. What I could imagine working are two eyes, but this would require, in my opinion, two developers with their own workstations working in a common workspace, each with an edit pane on the same code, but each with the ability to do independent research and to bring information to attention, etc.

In brief, no I don't have experience pair programming. :-)

Jimmy Chonga
Friday, March 07, 2003


Two different cases:

(1) You're using pair programming with a person who really doesn't "get" your language as way of teaching, say, perl or C++.  You let him be the driver and you tell him what to type.

(2) You BOTH "get" the programming language, and you are implementing a feature.  You understand the design better, so you let him be the driver and you talk about what do type.

In my experience, #1 will fail terribly (he'll type it but not know what he typed) and #2 is -wonderful-.  I've had nothing but success.  Bug count goes down, and speed -increases-.  Maybe not 2x, but, including all the breaks you skip because you drive through, it's pretty close.

regards,

Matt H.
Friday, March 07, 2003

What about two people in one common workplace (eg. cubicle), each with their own computer, understanding of the language, and design.  But while one guy writes the functions, the other writes the tests for those functions?

sedwo
Friday, March 07, 2003

I've tried it and really haven't been able to get into the groove with it.  When I work with good coders, I just seem to sit there, because they don't make mistakes or they catch 'em quick when they do.  When I'm working with a coder that's not so careful, I feel almost compelled to snatch the keyboard away after a little while, so I can get a little crabby.

When I'm on the other side and I'm doing the typing, the talking and whatnot interrupts my train of thought and rapidly becomes annoying.  Even worse is when we have a bug to puzzle out.  I'm trying to keep a lot of details in my head and I have a theory about where the bug must be located and it usually conflicts with the other guy's.  So he's announcing his chain of reasoning for me and telling me to check this and print that and I grind my teeth :)

Seems my temperament isn't well suited to this sort of thing except on an "as needed" basis.  Left to my own devices, I'm a pretty cheery fellow, too.

My team tried to enforce pair programming for a while, but no one really seemed to like it and it kind of fizzled out.  We're back to doing code reviews and writing individually.

What I do find extremely worthwhile, though, is pairing up for some design work.  I know the XP crowd eschews this, insisting that the code is the design, but I don't work that way.  I don't design the entire system in infinite detail up front, but I do like to have the "next few things" laid out and understood before I start typing at them.  I also like to have an outline made up before I start writing anything of consequense as well, so maybe it's just me.

Finally, I like to capture requirements using a four man team:  two developers and two customers.  I like to have one developer doing the interview and capturing the requirement, while the other one observes, asks clarifying questions, and so on. 

Having two customers is helpful because if there is even the slightest disagreement or misunderstanding between them they will debate it between themselves and get clarity without me having to try to pull stuff out of them.  Makes my job a lot easier.

pair designer
Friday, March 07, 2003

I've never really done pair programming, but I *love* pair debugging. Works great, having someone to discuss the problem with really opens up ideas, and two get to a solution much quicker than either individually would have.

Chris Tavares
Friday, March 07, 2003

The way we did it at my last job was myself and a fellow developer shared a large double cube. I found it a nice experience because we were building a website and he was an excellent client side developer (HTML, JavaScript, Photoshop) and I knew the server side aspects (JSP, Servlets, Beans).

Working together we taught each other a lot!!!!!

KenB
Friday, March 07, 2003

Tried it once with a guy who was a /massively/ quicker typist than me.  When he was coding, all my comments were four lines behind the cursor, and when I was typing it was 'why are you so slooooow!!!'.

We ended up hating each other in about 10 minutes so went back to being good colleagues with our own PCs.

UpAndDownTheCityRoad
Friday, March 07, 2003

I got to try it only once 'accidentally'. Two of us were working on the same problem and due to some constraint got to sit at the same terminal for sometime. So we started working together and actually finished both our tasks in less than the time it would have taken had we done it separately.

We did not know about 'Pair Programming' then, and we pleasantly surprised by it (in fact my collegue commented that together, we became better programmers than individually :-)

So I guess, there is something to it after all. The best thig that happened is that he caught mistakes (bugs) as I typed and I did as he typed. So when we compiled, we had pretty clean code that just worked!

satya
Friday, March 07, 2003

My ass is so wide, I take up 2 chairs.  All I need is a second personality.

Nat Ersoz
Friday, March 07, 2003

How does it work out if your pair partner likes to chew bubble gum and you have to listen him slurp, munch and pop while talking and typing?

z
Friday, March 07, 2003

It sounds like much of the experiences folks here have had is with something other than XP-style pair programming, which is a shame.

In XP Pair Programming, programming is performed by peers.  Both should be of roughly equal competence in the job they're doing.

Neither developer should be "jockeying for the steering wheel;" they should be alternating control of the keyboard.  The average seems to be to switch every fifteen minutes or so.

Neither developer should be just sitting there dumbly.  That's not pair programming; that's solo developing with an observer.

I've done pair programming in person, and over the 'net (using a shared desktop and talking over the phone), and it's been highly successful.  The code we've produced has been robust and powerful.

Brent P. Newhall
Friday, March 07, 2003

"In XP Pair Programming, programming is performed by peers.  Both should be of roughly equal competence in the job they're doing."

I think this is a fallacy of XP.  XP seems to call for a large team of generalist developers, each capable of working on any of the development artifacts.  Industry data clearly shows that teams of specialists outperform teams of generalists, however.  (See Capers Jones work as described in "Beyond Chaos" by Larry Constantine, ISBN: 0201719606).  Experience from other industries bears this out.

This generalist approach does have some benefits, most notably the ability to flexibly move developers to places where capacity is lacking.  Properly managing a team of specialists can avoid the problem altogether, though.  (Except, of course, for *the* system constraint as described in "The Goal")  In fact, because XP allows this movement of capacity, it may actually be the root cause of what appears to be a moving constraint/bottleneck.  This is a difficult situation to manage and even more difficult to predict effectively.

This "peer programming" model is also destructive to the goal of elevating the aggregate skill level of the team: you won't learn much from someone that's basically a copy of you.  My approach is to avoid it.

pair designer
Friday, March 07, 2003

I have tried it once for a school project, and it worked great for, I believe, these reasons:

1 - we each had our own keyboard (one PS/2 and one USB plugged in the same machine - it works)
2 - we each had our own pointing device (again, you can plug two mice in your PC, PS/2 and USB is what we did)
3 - we had different skills and hence different tasks
4 - there were two monitors, so there was that much more real estate to help us divide the tasks (they were not both showing the same image, we just had an extra big desktop to play with)

Specifically, we were putting together a model with Rational Rose RT.  My friend knew the modeling aspects better than I did and so his job was to create the capsules and the finite state machines.  Since I knew a bit of the software, I was able to provide input and help him.

I was in charge of the C++ source code that go in transitions and states.  Again, he knew a bit what was going on and he would help me.

It was great!  We would seamlessly tag team through the development process.  He would make a few clicks, type a few things.  If I disagreed, I could type something right away.  Then, when it was my turn to write code, he could interrupt me and say: "You forgot to declare that variable" and make the adjustment and I could resume coding.

There was no "uhhh, can you stand up so I can sit down at the keyboard to do that part?" that really gets annoying because it might be for a big five seconds before you're asked the same thing from the other guy.  We just typed when the other stopped.  Zero standing up and sitting back down time.

I'm not sure how useful it would be for a piece of software I would be doing for work, but I will definitely try it at my next job.

Olivier Dagenais
Friday, March 07, 2003

I have found that peer programming works well when both people have similar level of skill and understanding of the problem, as well as, compatible personalities. I think the latter is the key.

One of the most successful pieces of code I've ever written was done while "pair programming" with a friend, well before I've ever heard the term. However, on many occasions with other people it didn't work so well. Either I or the other person had much clearer idea of what to do and would up take over the process.

Hard-core XP advocates random pairings every day. I don't know how it could work in cases where people are not compatible or don't get along.

igor
Friday, March 07, 2003

I'll second the votes for pair designing and debugging.  It's great to have an extra pair of eyes and someone to bounce ideas off of.
A key point XP makes about pairing is that one person should be the "navigator" and one should be the "driver".  One focuses on design and the other on implementation.  You have to learn to let go, and not second-guess the other person too much.  My first pairing experience was hellish until I realized that I was back-seat driving, rather than navigating.
Other XP point - rotate partners, so you don't just become a clone.
All that said, I don't pair often.  Once you've figured out the implementation, the navigator isn't as valuable.  Also, with someone looking over my shoulder, I couldn't take the time to post on discussion groups.  ;)

Colin MacDonald
Friday, March 07, 2003


More remarks from someone who has never actually tried pair programming:

Of all the XP practices, this one has the most risk.  I understand the reward side of the equation (code reviews simultaneous with coding).  The risk is that the chemistry of the pair doesn't work.

Bottom line:  If the XP people were objective instead of fanatical, I bet they would admit the following is true:

When pair programming works, it works well, but it doesn't always work.

Eric W. Sink
Friday, March 07, 2003

I've had sessions where I worked with another programmer on a specific routine and it worked out OK. Our intention wasn't do to do "pair programming" per se, but just kinda ended up that way.

For me, I can see it being useful in very small and specific areas. But if I had to sit down with someone every time I wrote code, I'd wind up doing physical harm to someone.

There are times when I just need to sit there and think for a minute. I may have to try a few tests or go Google something for reference. When I'm doing this, I don't want someone sitting there breathing my air.

In the scenario I just described, how does XP recommend you handle that? Surely that don't ignore the fact that sometimes you just gotta think something through quietly by yourself before you get someone else's opinion on it?

Go Linux Go!
Friday, March 07, 2003

Many pair-programming advocates sound a lot like communists: They consider only the hypothetical positives while failing to see the realities of the human condition (i.e. egos, greed, self-gratification, inferiority/superiority complexes, etc). Yeah in theory it sounds brilliant that you could drop two people who could project each other into the stratosphere of productivity, but somehow the reality seems likely to be a tad different.

Jimmy Chonga
Friday, March 07, 2003

At my last job rather than pair programming,  every time someone started a couple day task he would partner with another person for a couple of hours.  We'd share the same PC and work through through several evolutions of a basic design,  bounce ideas off each other, question whether we were solving the correct problem, prototype some classes etc. 

Once ideas started to settle down, the person who owned the task would go back to his PC and pretty much work by themself. This seemed a good compromise since it addressed some of the problems of a person working in isolation, while allowing an individual to actually own the work, and do things thier own way.

I don't buy into the idea that two people sharing a keyboard are twice as productive as a person working alone.  I think the whole idea is naive.

What I think the XP folks are picking up on is that there are social obstacles that prevent many people from collaborating with thier peers as needed, and this causes a lot of problems. Unfortunately in most work environments this is viewed as asking for help, and is heavily stigmitized.

Eric Moore
Friday, March 07, 2003

Pair programming arises naturally among friends (in my experience), but not in corps.  With friends, you both care that the code you're using is up to snuff, so you observe each other, especially during that interesting point after a design has been sketched out and tools probed.  It's a great learning experience, to watch techniques and comment.  Often there are what are humorously called "creative differences" which are important and flesh things out further.

Eventually, I suspect the need to be close during implementation becomes patchier.  At that point, you might be able to scan the other guy's CVS or just eyeball the code and notice little lends itself to interesting comment.  But I haven't gone there yet.

Corp environments often feed weird ego neuroses and make it hard to have the trust necessary.

Tj
Saturday, March 08, 2003

Testimonial from one of those badass-sounding teams.
http://home.earthlink.net/~kend0/ExtremeSuccess.html

Tj
Saturday, March 08, 2003

Pair programming works great, as long as each person is capable, each has their own keyboard and mouse hooked to their own (networked) machines, and they are each working on a different task. Ideally in separate rooms.

If your IDE isn't catching your typos, look into a better IDE.

Robin Debreuil
Saturday, March 08, 2003

As we now know, participating in this forum is best done as a pair - one person to make posts and the other to find out whether they were write-once-read-once or write-once-read-many

Ben Wint
Saturday, March 08, 2003

Where I work, if I try to collaborate with someone to find a bug in my program, they think I'm asking them to do it for me. They might say "try different things and narrow it down," or "keep notes of what you have already tried." Either that or they take over and fix the bug and ignore me. They have not read XP I guess.
Everyone works alone and solves their own problems. I don't mind, but it can take much longer. For example, I'm currently learning how to use software that I was not familiar with at all, while someone else in the department knows it inside out. Nevertheless, I am struggling alone because that's the only way to appear competent in this department.

The Real PC
Saturday, March 08, 2003

Sounds like a problem, but don't confuse two people talking with each other with 'the goodness XP at work' either...

Robin Debreuil
Saturday, March 08, 2003

I didn't mean to. I really don't like the idea of pair programming at all. On the other hand, I would like to feel I could talk about problems. I get answers from the people I work with like "try searching in google." Well duh.
At least with pair programming you get to talk about problems and work together. However, I like working alone even if it seems like a waste of time when I know someone down the hall could give me the answer in 2 minutes. They spent hours finding the answer the first time, and now I'm spending hours finding the same answer. Seems like a waste. But if they want to pay me for that, I don't mind.

The Real PC
Saturday, March 08, 2003

Sort of like Web Services, it's so easy when one can give absurdly trivial examples. If it's good having one coworker working alongside you to share their prior problem solving experience, why not two? How about 4? How about the entire company all huddles around one PC so they can use the collective knowledge of all of them? Of course this is absolutely ridiculous.

Many of the bogus examples to support pair programming exist in software development TODAY: Got a problem that you think coworkers may assist with? Asynchronously email coworkers and shift gears and work on something different for a while. Hell, perhaps check Deja (err, Google Groups) or other online resources (which is a HUGE collective...a super pair programming if you will).

Jimmy Chonga
Sunday, March 09, 2003

Jimmy C., are you working at a company where management forces people into the coolaid of the week?  Normally, people just consider the pros and cons, trying to see where it would and wouldn't work.  Whereas you come out swinging, saying you've never tried it but it's Communism.  It's like you're in an environment where you have to fight the trendy coolaid.

anon
Sunday, March 09, 2003

Personally when I work, I don't like to be bugged. I don't mind at all if I've just finished a task, look up, and go get a drink of water, but while I'm in the middle of something I find it very aggrivating. Point 2 is that just because I did something similar a month ago, it doesn't mean I'm in an expert and can spit out the code without reference. Probably, if it was tricky,  I had the docs on one screen, and possibly a few googled sites and sample code on others. Eventually it all gets peiced together and I keep going. Next time I'm faced with the problem, it is a lot more familiar, but it still involves checking, and certainly dropping whatever else I may have been thinking about.

So when someone asks for help it can either be no problem at all, or intensly aggrivating, depending on when its asked, as well as what the question is. If a person is in the middle of something, you really shouldn't barge in period. Also, if the question is something that can be answered by documentation, looking at my old code, or google, don't waste my time please! Why should I look up your problem? In fact, that is what you are paid to do, just like me. Good questions address things like implementation strategies, quirks that are outside the docs, vaugness of specs, tips and tricks, and above all, things you have already tried to figure out and couldn't. Annoying questions are things that can be looked up more easily than answered, or worse (and more common!), someone is bored and wants a break. If my question doesn't start with 'I can't figure this out...', I tend to hold off until it does.

I think 99% of what you program can be looked up, and most of the other 1% either requires 'project consensus' rather than 'pair consensus' or an individual with a greater level of expertise in the subject. It makes me deeply suspicious of pair programmings claims. The lack of *reproducable* results are usually attributed to 'the programmers didn't get it', 'the mix was wrong', 'the attitudes were too old school' or 'the sun was in my eyes'. Anyone who doubts it is pretty quickly dismissed as narrow minded with an invalid opinion. This is probably why it starts sounding like religion or communism, it is a familiar pattern to those with experience in those areas...

But hey, not to say it can't work, just it has been running for a while now on claims alone.

Robin Debreuil
Sunday, March 09, 2003

There is a lot to be said for working alone, even when there's an expert down the hall.
Last week I had to do something unfamiliar and there wasn't much documentation. And nothing at all that explained it on a beginner's level. I asked the expert for an introductary explanation and he told me a lot but no simple instructions about how to get started. Then he went away to a conference and I just struggled with it for two days. Eventually I got things to work and now I feel I have a pretty good understanding. Much better, maybe, than if he had helped me.
If he had been around I would have felt I had to ask for help in order to save time. Since I had an excuse to do it all alone, I wound up understanding it better and also feeling better about myself, because I didn't need help after all.
On the other hand sharing information and helping each other out makes sense at times. Otherwise, everyone could just work at home.

The Real PC
Sunday, March 09, 2003

What nature of experimental results would lead you to reexamine your opinion that pair programming can't work?

Danil
Sunday, March 09, 2003

If you are talking to me, I didn't say it 'can't work', just they make a lot of claims without backup. What kind of experimental results? Well, how about the unbiased empirical type? Eg, the ones that don't look like they are from either side of the global warming debate. There are plenty of studies where the basic aim is to figure out what increases productivity in the software world, just that. Most of what I've read on pair programming jumps right in to 'why' it is more productive, but never establishes that it is. Kind of like all the 'why linux is faster' talk you used to hear a few years back me thinks... But hey, if it comes out that it actually works, great.

PS that does not put me in the waterfall camp, nor the camp of social mistfits, nor the camp of enforced solitude. That wiki link at the start is an embarassment! And making credible by calling it a 'design pattern' lol! And all this while I thought patterns were supposed to have a 'liabilities' section - oh, I guess there are none in this case... Even more credible then! I guess that is the kind of thing that turns me away, life is too short to spend debunking things that look that much like psuedoscience. Basicaly if is better, it can be proven to be. And people will no trouble adopting it if it works better either, history bears that out...

PPS Of course everyone programs with other people around when it is useful, that says nothing other than people use common sense...

Robin Debreuil
Sunday, March 09, 2003

My most enjoyable days doing anything have come when I work in pairs.

Things pair programming is good for:

1. Avoiding Stupid mistakes (arithmetic ...)
2. You have two brains to think about the implication of design deciscions
3. One guy can hold of the manager, make a phone call, answer peoples stupid questions, lookup something in the docs, while the other finsihes whatever was just talked about (easier to maintain flow).

For it to work though they must be close in skill level/confidence in their skills otherwise one of them will tune out.

Daniel Shchyokin
Sunday, March 09, 2003

Did anyone notice on that link[1] that the opening quote says:
"...has shown that paired programmers are only 15% slower than two independent individual programmers..."

ummm, but the rest of the page says you will be much faster? And less bugs, please specify - bug reports from the test team, or compiler caught typos etc that take no more time to correct when the compiler tells you than the person sleeping beside you does.

Also it goes on and on about pairing up a junior and senior, so which is it? There isn't even consensus about something as basic as that?

Well, I guess life is too short, but one can always find time on a slow night too...

Robin Debreuil
Sunday, March 09, 2003

Yes, something about koolaid...

Interestingly my comments regarding pair programming have not bee overly negative, and I personally don't really have an opinion regarding them, however I DO have a cynicism about the latest great thing that people have a horrible tendency to want to advocate something different, so they over-emphasize the positives while failing to consider the negatives...like communism.

Jimmy Chonga
Sunday, March 09, 2003

I drink a lot, so on those days when my head hurts, it's really good to be team programming with a zealous young programmer, I just sit quietly and utter the odd wise sounding noise of agreement, occassionally I type too.

Usually, with my experience, I can spot any youthful bad decisions pretty quickly and head them of at the pass, sore head or not.

A win - win situation.

Realist
Sunday, March 09, 2003

Why not create a new thread arguing why PP sucks in an a priori sense?  This one is about peoples' anecdotal /experiences/, good or bad, not about advocacy.

Not that my "unprofessional" experiences were educational, but at least they were ontopic. ;)

Tj
Sunday, March 09, 2003

I like working in pairs when it arises naturally. Usually this begins with someone showing up with a problem, and you end up spending half a day at his desk, usually both learning a great deal from the experience (if it was trivial it wouldn't take half a day, right).
To extend this to working in pairs all the time seems to me like spoiling the broth by keeping it on the stove for too long.

Just me (Sir to you)
Monday, March 10, 2003


This is easily the most "controversial" of the XP practices.

I've worked on two XP projects for 4, soon to be 5 releases. We do pair programming all the time.

A couple of points, in no particular order:

1) Our, admittedly empirical, experience is that pair programming reduces defects and improves design without noticably reducing speed.

2) It's great for mentoring.

3) Pair debugging is great.

4) We've even got our QA team involved. They do pair testing.

5) People who are afraid of pair programming often come up with horror stories to show why it won't work for them. Their co-workers are smelly. They can't think. Whatever. That's fine. If you don't want to pair program, then don't. But my advice would be to do the right thing and excuse yourself from any team that's trying to do XP because you will end up sabotaging said team.

6) If co-workers do have bad habits that prevent effecting pairing, those habits are already probably making it difficult to get the best out of the team. Someone is going to have to suck it up and talk with this co-worker. Their boss should have already.

7) If you can't explain your idea/design to a partner at a keyboard, it's probably not that good a design in the first place (many will likely argue with this, but I stand by it). That includes someone who is less skilled than yourself. If you can't make a junior programmer understand your design, I strenuously urge you to take the time to re-examine it yourself.

8) One of the keys to effective pair programming is to have one person, the person with the keyboard think "tactically", or about the code, while the partner thinks "strategically" or the goal of the coding session. This really helps keep things from falling through the cracks.

Just my experiences

Bruce
Monday, March 10, 2003

"If you are talking to me, I didn't say it 'can't work', just they make a lot of claims without backup."

On the other hand, people are just supposed to accept that you work faster by not pairing, right? Where's the evidence there?

I'm not being argumentative, but really comparing pair programming to the alternative is difficult to say the least. First, most developers think they're done with a task when they check in the code. Time required to go back and fix bugs never gets factored in. This alone makes it difficult to properly assess pair programming as it's major goal is to reduce bugs.

Now, you might be doing code reviews. That's great, but it takes time too.

They THEORY is:

    Tpp <= Ts + Tb + Tcr

Where

    Tpp = Time spent on a job using pair programming
    Ts = Time spent on a job standalone
    Tb = Time spent fixing bugs as a result of Ts
    Tcr = Time spent in code review

Of course, if you're not doing code reviews in the first place, the pair programming has obvious benefits besides any time saved.

If the theory works for you, great. If not, too bad, you'll have to find something else that works. No hard feelings.

Bruce
Monday, March 10, 2003

Well, lots of things are hard to prove, but they have been proved, or at least people have come to somewhat of a consensus (OO for example). Of course the first step in measurement is definition, and that seems to still be pretty vauge. I guess projects that had good stats and weren't "sabatoged" by "People who are afraid of pair programming...". Btw, what, on earth, would make someone afraid of pair programming, or was that just a favorite verb to use on thouse who disagree with it? Am I a fraidy cat then?

As for my proof that programming alone is faster, I don't have any. Then again, I'm not making the claim here. I don't have any proof that ufo's don't buzz cornfields either. The onus is on the person making the claim, sorry...

I am certain (barring good hard evidence otherwise) there are times when it pays to work in groups, or pairs, or alone, and there are different times and situations that lend themselves to each. I assume you agree. It is very hard to mentor someone when you are locked in a room alone for example, no reasonable person would dispute that. I have seen good things working with others on debugging too, especially certain categories of bugs. I totally agree with your 'explaining design' part too, though if you are commenting and documenting things the need to 'explain' comes up fairly often too.

There is a great contribution to be made if someone could show when and where each is stronger. Unfortunately the whole subject has been framed as an all or nothing question, which only gives rise to name calling, religion and above all, smugness. I'm sure it will stunt any research on the subject for years, much like brand loyalty killed most of the useful UI debate.

Oh well, back to work, the old fashioned way...

Robin Debreuil
Monday, March 10, 2003

Is "time" the only measure of interest? How about cost?

"They THEORY is:

    Tpp <= Ts + Tb + Tcr

Where

    Tpp = Time spent on a job using pair programming
    Ts = Time spent on a job standalone
    Tb = Time spent fixing bugs as a result of Ts
    Tcr = Time spent in code review
"

I would posit:

Tpp x 2 x (dev cost/hr) <= (Ts + Tb + Tcr) x (dev cost/hr)

if two programmers work as fast as one programmer but writer fewer bugs, then you're paying twice as much for your more stable code, right? The wiki article says "In summary: Get two people Programming In Pairs, and they'll work more than twice as fast as one could have." - it seems that THAT is the statement that needs scientific support.

Philo

Philo
Monday, March 10, 2003

When to pair:

- We insist on pairing for new features.
- We insist on pairing for the nastier bugs.
- We generally don't pair, or don't insist on pairing, for:
  - Installer work
  - Support work, like test data, etc.
  - Scripting
  - Trivial or relatively straightforward bugs

But I'd also like to address the perception (by me, at least) that XP is "thou shalt pair". To me, XP is "thou shalt use your head". If pairing makes sense, do it, and don't make excuses to avoid it. If it doesn't make sense, why would you want to insist on it?

I "coach" (whatever that means) two teams. One has only two developers. Making them pair all the time would be silly. It essentially makes the project "single threaded".

We have one story that represents a major new piece of  functionality. Our plan is to have them pair the "foundation" bits so they both have a good grasp of the fundamentals, then divide the work sensibly so they don't collide and then let them work independently. To us, this makes sense.

I guess I also need to go back and explain my comments on watching for "sabotage". We've actually had to let one person go because he would not pair. I've seen examples of others who mouthed the words, but in the end worked to defeat pair programming, probably unconciously. This is the worst case scenario as it muddies the water and makes it even more difficult to tell if pair programming fits your organization and if it helps you.

As for proof, I don't think you're going to get it. At least, not the kind of hard evidence you appear to be looking for. We accept programming alone because that's what's always been done. There's no proof it works better than pairing, but it's the standard so it's accepted as dogma. Our experience, again empirical, is that it can actually be detrimental to a project.

Bruce
Tuesday, March 11, 2003

*  Recent Topics

*  Fog Creek Home