Pair programming sucks

[Mike Isano]

XP endorses pair programming. I absolutely HATE pair programming. I can't think with people sitting next to me. I am less productive.


The idea behind pair prog is that your friend will be constantly reviewing your code, giving ideas, etc. But really it just makes me feel like i'm being watched. And if I'm the one who is doing the "watching" after a while my mind starts to drift away.

I prefer the old fashioned way of spliting up the project into seperate chunks, and you work on your chunk. Does anyone else feel this way?

[Ilja Preuss]

Pair Programming is a skill that needs to be learned like any other skill - it is unrealistic to expect it working find the first time you sit together on one computer. (I'm not implying that you did, but I find it important to mention it.)

When you find like you are "watching" your partner code, there certainly is something going wrong. It really should more feel like you two code *together*.

One thing you could try is to think out aloud while being the driver. Make sure that your partner understand every move before you do it. Encourage him to offer his own ideas and variations. A lot of the value of Pair Programming actually comes from the creativity increase from discussing your ideas with a partner while coding them down.

Likewise, when you are the navigator, ask a lot of questions. Think about the strategical impact of what your partner does - typically being closer to the code will let him focus on tactical matters.

Some more interesting etudes can be found at http://www.xprogramming.com/xpmag/Etudes.htm#N84

[Gabriel Claramunt]

Well, I guess some people like it, others don't. If it doesn't work for you, don't do it. "People over process"
Keep in mind that Pair programming is a fundamental practice of XP, though, and is hard to keep the other practices without it.
Personally, it doesn't work for me either... I prefer to think strategically first together and then tactically alone while programming.

[Jeanne Boyarsky]

Originally posted by Mike Isano:
And if I'm the one who is doing the "watching" after a while my mind starts to drift away.

Sometimes this is a sign of not rotating the keyboard often enough. How often do you switch typing when pairing?

[Ilja Preuss]

Originally posted by Gabriel Claramunt:
Well, I guess some people like it, others don't. If it doesn't work for you, don't do it. "People over process"

Be careful to not use "People over Process" to prematurely reject a practice. If it doesn't work for you, the first thing you should do is trying to find out whether the people for whom it works are doing something differently, or more generally what you can try to make it work for you. Only after you have done that, have given it a reasonable try for some time and allowed yourself and the rest of the team to get good at it, you can seriously make an informed opinion on whether it really works for you or not. All in my not so humble opinion...

[Paul Croarkin]

I reject the assertion that it is hard to keep other XP / agile practices if you are not pair programming. You can certainly have daily stand-up meetings, do continuous integration, do test-driven development, etc without pairing.

We do pairing on an ad-hoc basis. Sometimes the pairing will be determined during the planning meeting ("Joe and I will pair on task X") and other times it is spontaneous ("Mary, can pair with me on this for an hour?").

Personally, I find that pairing can really help you focus on a task, but I would also go crazy if I had to pair every single day all day long.

[Gabriel Claramunt]

I'm referring to XP, where every practice relies heavily in the others. Pair programming in XP allows the non-driving pair to do design and perform code/unit tests review "on the spot", so in XP there's no need of design or reviews, and the pairs can work directly from the user story. If you take the out the pairs, you'll need to compensate or you have a higher risk of lower quality code, design, and unit tests (a problem if you're doing militant refactoring). Collective code ownership will suffer also, because the knowledge about the code is not acquired during pairing (and lower quality unit tests will compound the problem).
Anyway, I'm not XP guru and maybe I'm totally wrong
... just be careful
(for a more "evil" view on the issue, you can see The Case Against Extreme Programing: A Self-Referential Safety Net)

[Ilja Preuss]

Originally posted by Gabriel Claramunt:
I'm referring to XP, where every practice relies heavily in the others.

It's true that they very well support each other. "Heavily rely" on each other I find is kind of an exaggeration.

Pair programming in XP allows the non-driving pair to do design and perform code/unit tests review "on the spot", so in XP there's no need of design or reviews, and the pairs can work directly from the user story. If you take the out the pairs, you'll need to compensate or you have a higher risk of lower quality code, design, and unit tests (a problem if you're doing militant refactoring). Collective code ownership will suffer also, because the knowledge about the code is not acquired during pairing (and lower quality unit tests will compound the problem).

Well, yes, of course not doing Pair Programming will not give you the benefits of Pair Programming - that's why it's recommended. As far as I can tell, it's still better to do the other practices then not to do them. If you do some additional ones to compensate for the missing Pair Programming, all the better, or so it seems to me...

(for a more "evil" view on the issue, you can see The Case Against Extreme Programing: A Self-Referential Safety Net)

Let's just say that the author of that pamphlet is far from being an XP guru, either. Let alone that the "loop" is a poorly executed rhetorical trick - if you look closely, you'll see that there isn't a true dependency loop at all.

[Guy Allard]

Originally posted by Mike Isano:
XP endorses pair programming. I absolutely HATE .... Does anyone else feel this way?

Mike - If it works, use it. If it does not work, do not use it.

Very simple.

Guy

[Ilja Preuss]

Originally posted by Guy Allard:

Mike - If it works, use it. If it does not work, do not use it.

Or make it work, for example by getting better using it, or using it differently.

[Rahul Bhattacharjee]

Originally posted by Mike Isano:

The idea behind pair prog is that your friend will be constantly reviewing your code, giving ideas, etc. But really it just makes me feel like i'm being watched. And if I'm the one who is doing the "watching" after a while my mind starts to drift away.

Well : You would also be doing the same for him. So why it sucks ?

Its good from the project management prospective when teams boss knows that there isn't any part of the information with only one person.He can relax too.

[Junilu Lacar]

Pair programming is obviously one of the more, if not the most, contentious XP practice to introduce to a team. I have had mixed success with it myself. It depends largely on the person I try to pair with. Negative reactions run the gamut from indifference to outright hostility. If you can get people to take a step back and objectively re-examine the approach and try to get PP right as Ilja suggests, that's great. The important thing is to not force it on people.

The guys on my current team are a mixed bag. There are some folks who absolutely will not do PP or are so nonplussed by it that it becomes counterproductive. There are a couple who are open to it but only to a certain extent. After a while, however, they will invariably request to be left alone to complete the code. I still PP with them whenever I can find an opening to do so (usually on the pretense of doing a code review, design review, or having an idea for a boundary condition that needs a unit test, etc.)

I think a good way to slowly build up a favorable environment for PP is to start with TDD (test-driven development) since there is an almost natural progression from TDD to PP. TDD can be done solo but presents many opportunities for someone to come in and offer to help. I also find that TDD makes people who normally work alone open to getting help from a teammate. Hopefully sooner or later I won't have to offer help any more, just accept requests to PP.
[ September 19, 2007: Message edited by: Junilu Lacar ]

[Paul Carter]

Pair programming would absolutely drive me nuts! Programming is a difficult task which requires concentration and freedom from distractions. The only thing I can think of that would be less helpful than having another programmer sitting next to me while I work would be to also be working in one of those idiotic bullpens that some people are so crazy about.

[Ilja Preuss]

Originally posted by Paul Carter:
Pair programming would absolutely drive me nuts!

Have you tried it with someone who is good at it?

Programming is a difficult task which requires concentration and freedom from distractions.

Studies show that Pair Programming actually helps people to get less easily distracted, and to get back into flow faster once they got distracted.

The only thing I can think of that would be less helpful than having another programmer sitting next to me while I work

But that's not Pair Programming. Pair Programming is about sitting *together* in front of a computer, and *collaborating* on getting a task done.

would be to also be working in one of those idiotic bullpens that some people are so crazy about.

When I joined my current company six years ago, we all had private offices. When the team grew, we went out of space and had to move into an open office (with five developers at that time). We were all quite skeptical, but agreed because it was supposed to be a temporary solution.

A year ago we moved into a bigger building, and the whole team was quite disappointed that we couldn't get a room that was big enough to hold us all. Most of the time we actually still managed to all work in one room; though it wasn't that smooth an experience, it was still better than working in different rooms.

Just recently we grew to eight developers, and managed to get a room big enough to hold the whole team. It's a great relief to all of us. No one would have wanted to move into a more private space.

The important part is that we are really one team, all working on the same project (although often on different parts of it). The osmotic communication resulting from the collocation really is invaluable. We couldn't stand it if there were also people in the room not working on our project, though.

In my opinion, the next big move would be to also have the technical writers in the same room. We really lack communication in that respect.

[Damon Black]

Have you tried it with someone who is good at it?

I've been working in XP shops for the last 2.5 years - exactly as long as I've been employed as a programmer (recently changed careers). I got into programming because I thoroughly loved it. I found that I was taking off work at my old job so I could stay home and code all day. After my experiences with XP in general, and pair programming specifically, I find I'm back in the same boat: I'm taking off work so I can stay home and code.

I've tried pair programming with at least forty different people by now and it's never been a productive experience. Working with someone who is 'good' at it makes it less painful, and I've often learned a lot from working with more experienced programmers, but ... When I code by myself I can usually get myself in stretches of intense concentration, where I'm 'thinking in code'. Everything makes sense and I'm able to keep all the dynamics of whatever module I'm working on in my head at once. I NEVER get to that state of mind pair programming. Even with the best of them.

Studies show that Pair Programming actually helps people to get less easily distracted, and to get back into flow faster once they got distracted.

Studies may show this for some people. For me it's been exactly the opposite.

But that's not Pair Programming. Pair Programming is about sitting *together* in front of a computer, and *collaborating* on getting a task done.

I do agree there are some tasks that benefit from this approach. I especially think that when you're going to be making architectural decisions that affect many areas of code, working with other people is essential. But the thing I can't seem to do (and I acknowledge this is likely just a personal weakness) is 'think along' with someone else. I even find myself avoiding needed refactorings or explorations because of the additional headache of having to negotiate with your pair partner to do so.

would be to also be working in one of those idiotic bullpens that some people are so crazy about.

This is what I'm currently working in. Combined with pair programmer, it provides the added din of distraction that makes it virtually impossible for me to get anything done. It's like working in a grade school cafeteria.
[ October 10, 2007: Message edited by: Damon Black ]

[Lasse Koskela]

Originally posted by Damon Black:
I even find myself avoiding needed refactorings or explorations because of the additional headache of having to negotiate with your pair partner to do so.

So what are you going to do about this?

[Ilja Preuss]

Damon, this is an interesting report. I'm curious - please allow me to inquire a little bit...

Originally posted by Damon Black:
When I code by myself I can usually get myself in stretches of intense concentration, where I'm 'thinking in code'. Everything makes sense and I'm able to keep all the dynamics of whatever module I'm working on in my head at once. I NEVER get to that state of mind pair programming. Even with the best of them.

What do you think is it about pair programming that holds you from "thinking in code"?

I totally agree that the state of mind when pair programming is different from the one when working alone. I don't find that that state of mind is less productive - whether it's less enjoyable may certainly be something personal, though.

One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?

--------------------------------------------------------------------------------
Studies show that Pair Programming actually helps people to get less easily distracted, and to get back into flow faster once they got distracted.
--------------------------------------------------------------------------------



Studies may show this for some people. For me it's been exactly the opposite.

Those studies show it for a high percentage of people, though I can't say how representative they are.

Can you say what lets you get distracted easier when pair programming?

I do agree there are some tasks that benefit from this approach. I especially think that when you're going to be making architectural decisions that affect many areas of code, working with other people is essential.

Yes, that's something I thought, too. After having tried pair programming on a lot of different tasks for a couple of years now, I've found that there is virtually no task I can think of that wouldn't benefit from pair programming (assuming it done well, of course).

But the thing I can't seem to do (and I acknowledge this is likely just a personal weakness) is 'think along' with someone else.

Yes, working together is not always easy, and you certainly need to adapt your PP style to the people involved. Finding that style and making it work may take some time and practice. You have to decide for yourself whether it's worth the hassle.

I even find myself avoiding needed refactorings or explorations because of the additional headache of having to negotiate with your pair partner to do so.

I actually had the same problem with one particular partner in my team. Since we started to talk about it, it's improving. We even hold small mini-retrospectives at the end of a PP session, to look at what went well and what didn't, and to find working agreements that will make us pair program even better the next time.

This is what I'm currently working in. Combined with pair programmer, it provides the added din of distraction that makes it virtually impossible for me to get anything done. It's like working in a grade school cafeteria.

It's natural that there is kind of a buzz in the team room, but it shouldn't feel like working in a cafeteria. Again, a healthy team room atmosphere in my experience isn't something that happens automatically, but that needs to be worked on. For example, one thing we did was installing small bells on each table that you could ring when it got too loud in the room - just as a reminder to your colleagues to tone down their voice. We also have a policy that long lasting phone calls need to be made from a different room.

[Ernest Friedman-Hill]

Originally posted by Ilja Preuss:
For example, one thing we did was installing small bells on each table that you could ring when it got too loud in the room - just as a reminder to your colleagues to tone down their voice.

That sounds like a wonderful idea -- I'll try that the next time the opportunity presents itself. Far less disruptive than saying "Shhh" or "Quiet down please!", and at least potentially anonymous, too.

[Damon Black]

Originally posted by Ilja Preuss:
Damon, this is an interesting report. I'm curious - please allow me to inquire a little bit...

No problem. I should have plenty of time since I was 'let go' today for my inability to bend my 'people' to their 'process'.

What do you think is it about pair programming that holds you from "thinking in code"?

I think I'm in a different place in my brain when I'm programming. And it's nowhere near the place where I deal with interpersonal communication. Each time my partner says something, sighs a little loud, or even fidgets in their chair, my attention is diverted away from the kind of thinking I need to do when programming.

One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?

Not much. I know it's what needs to happen for engaged pairing - and I've really tried to do it. But as tedious and frustrating as it is to watch someone else program, it's even worse trying to program and not being able to maintain a consistent train of thought. When your pair partners all seem to prefer it that way, it's just much easier.

Can you say what lets you get distracted easier when pair programming?

It's not that I'm more easily distracted, the problem is that there's much more distraction. I'm actually probably a little more easily distracted programming by myself, my thinking tends to be more relaxed and creative. But I deliberately work (when given the choice) in an environment where I can remain free of unwelcome distractions. The problem with pairing is that the distractions are so much more frequent and intrusive.

It's natural that there is kind of a buzz in the team room...

I liked your idea about the bells and passed it along to our team, before I got fired that is.

The 'not-noise' is the real distraction of the bullpen stuff. It's tough NOT to listen to another human voice, especially if the voice might have important information for you. Someone might be just be clearing their throat, or making a joke, but you have to listen for a second to discern that, and as I've said, that's a jarring shift in perspectives for me.
[ October 11, 2007: Message edited by: Damon Black ]

[Ilja Preuss]

Originally posted by Ernest Friedman-Hill:

That sounds like a wonderful idea -- I'll try that the next time the opportunity presents itself. Far less disruptive than saying "Shhh" or "Quiet down please!", and at least potentially anonymous, too.

Yes, the positive side is that it's much less disruptive and there seems to be a lower barrier to actually use it.

On the not so good side: the bells we have have a rather "aggressive" sound, which cause some tensions. If I had to do it again, I'd search for some kind of tool that makes a more pleasing sound. Of course it shouldn't be too pleasing...

[Joe Harry]

Did you guys mean Parallel Programming by Pair Programming?

[Ilja Preuss]

Originally posted by Damon Black:
No problem. I should have plenty of time since I was 'let go' today for my inability to bend my 'people' to their 'process'.

Sorry to hear that. It's hard to say from the distance, but it doesn't sound like there was a lot of effort to try to work on your problems...

I think I'm in a different place in my brain when I'm programming. And it's nowhere near the place where I deal with interpersonal communication. Each time my partner says something, sighs a little loud, or even fidgets in their chair, my attention is diverted away from the kind of thinking I need to do when programming.

That's strange, because when pair programming, you should constantly be communicating with each other, anyway.

I assume you didn't have a coach that helped you with the adoption of pair programming?

Did the team already do pair programming when you joined?

--------------------------------------------------------------------------------
One more question: when you pair program, how much of the time do you find yourself being the driver (the one typing at the keyboard)?
--------------------------------------------------------------------------------


Not much. I know it's what needs to happen for engaged pairing - and I've really tried to do it. But as tedious and frustrating as it is to watch someone else program, it's even worse trying to program and not being able to maintain a consistent train of thought.

I think the trick you need to learn for pair programming is "thinking out loud". That's something that doesn't come naturally to all programmers, but I've seen the most introvert developer I've ever met learn it in a year and then prefer it over his old way of working. Your mileage may vary, of course.

It's not that I'm more easily distracted, the problem is that there's much more distraction. I'm actually probably a little more easily distracted programming by myself, my thinking tends to be more relaxed and creative.

That's interesting. Every single developer I know is more creative when working in a pair - simply because of the stimulation by thoughts from a second brain. Being relaxed is a prerequisite, of course, and that might take some work to accomplish.

But I deliberately work (when given the choice) in an environment where I can remain free of unwelcome distractions. The problem with pairing is that the distractions are so much more frequent and intrusive.

If those distractions are coming from your pairing partner, then that's certainly not the intent of pairing. It's also something I've only seen in pairing that could be improved.

Distractions from other pairs actually seem to be less a problem when you are pairing yourself, too, in my experience.

I liked your idea about the bells and passed it along to our team, before I got fired that is.

The 'not-noise' is the real distraction of the bullpen stuff. It's tough NOT to listen to another human voice, especially if the voice might have important information for you. Someone might be just be clearing their throat, or making a joke, but you have to listen for a second to discern that, and as I've said, that's a jarring shift in perspectives for me.

As I said above, I find that that seems to be less of a problem when working in a pair yourself - to an amount that the benefits are worth the distraction. Again, this will of course strongly depend on the nature of the team, on the team environment and on the skills of the team members.

[Damon Black]

it doesn't sound like there was a lot of effort to try to work on your problems...

It's actually been an issue for several months. As a new programmer, I'd mostly assumed my level of discomfort was due to inexperience. As I've learned more and become more confident in my skills, I've seen something different at play. The pairing has become the single biggest impediment to my effectiveness at work.

As far as efforts to work on my problems, there really hasn't been much. They've been patient with me, I suppose, but they've also been very clear that 'pairing is what we do here'. Most of my effort was directed at trying to get better at pairing. In the last few weeks, as that began to seem more and more futile, I started trying to persuade our team, and by extension the company, to be a little more flexible in our application of 'agile'. They seem to have had much less patience with that approach.

That's strange, because when pair programming, you should constantly be communicating with each other, anyway.

I understand that. But for me, unfortunately, that equates to constant distraction.

I assume you didn't have a coach that helped you with the adoption of pair programming?

Did the team already do pair programming when you joined?

We do have a coach, but his job seems to be more about laying down the law on what our practices will be, rather than helping us implement them. The company had recently done a full scale conversion to XP shortly before I got there, and I get the impression that they feel that if they give in at all to those resisting the change, it will all come unraveled.

I can even understand to a point. In XP, pairing is the glue that holds the whole process together. Without code reviews (something that sounds like a great idea to me, btw), pairing is the only way team knowledge and quality control really happen in XP. But I've never seen it function particularly well in that regard. Even amongst those who can tolerate, or even enjoy, pairing, the results are random and spotty. Our code is full of half-baked attempts to apply various design patterns or refactorings, only to be abandoned by the next pair to touch the code (we swap pairs - and tasks - often, which ensures maximum vertigo for me) who either didn't understand what the previous pair was up to or decided things should go in a different direction.

I think the trick you need to learn for pair programming is "thinking out loud".

That does seem to be the key. Even harder, for me, is "listening while thinking". I can do this in most situations, I enjoy conversation and I'm pretty good at it. I'm not one of these techie-nerds with no social skills. But I do prefer to have only one voice in my head when I'm programming.

That's interesting. Every single developer I know is more creative when working in a pair - simply because of the stimulation by thoughts from a second brain. Being relaxed is a prerequisite, of course, and that might take some work to accomplish.

Well I guess I can be your first counter-example. Most of the developers I know (and nearly all of them are from the agile shops I've worked in, where pairing is the norm), tell me that they do their best coding alone. In theory, I can see how pairing offers benefits to creativity and productivity, and benefits to team knowledge, etc.. - but my experience has been that the practice is so fragile, and so dependent on highly disciplined techniques, that it makes a poor choice for routine practice. I'd certainly not want it to be the norm if was signing the paychecks.

Thanks for the comments, btw. Hopefully you can understand how I might be coming at this topic from a particularly negative place right now, but I'm trying to keep my observations as honest and unbiased as possible.
[ October 12, 2007: Message edited by: Damon Black ]

[Cameron Wallace McKenzie]

As a lead developer, or heaven forbid, a project manager, I have seen much greater productivity out of my fellow developers when doing pair programming, even when they don't like it. My personal experience is that it works, and it makes developers more productive.

-Cameron McKenzie

[Ilja Preuss]

Damon, thanks for the honest report.

I still sense some dysfunctional behavior in that team. For one thing, it doesn't sound like the coach filled that role in a way that it would align with what I'd see as the responsibilities of such a person. I also wonder whether the team did iteration retrospectives where such issues where discussed openly.

Anyway, if we ever meet, I would be highly interested in trying some pair programming with you, just to see what happens. I'm sure we both would learn something from the experience...

[Stefan Bell]

Originally posted by Cameron McKenzie:
As a lead developer, or heaven forbid, a project manager, I have seen much greater productivity out of my fellow developers when doing pair programming, even when they don't like it. My personal experience is that it works, and it makes developers more productive.

-Cameron McKenzie

As a lead developer and technical architect, I have experienced mixed results. Some of our most productive and talented programmers have not faired well in PP. I know what Ilja will say, but we tried different partners, coaching, basically everything and it just didn't improve. The others and particularly the junior developers thrived in it.

My two cents.

[Damon Black]

Originally posted by Ilja Preuss:
Anyway, if we ever meet, I would be highly interested in trying some pair programming with you, just to see what happens. I'm sure we both would learn something from the experience...

I'm sure of it! I can actually enjoy pairing, if the point is mentoring, or if one partner is looking for specific advise in some area. But if the point is be 'productive', it doesn't get me where I need to be.

Originally posted by Stefan Bell:


As a lead developer and technical architect, I have experienced mixed results. Some of our most productive and talented programmers have not faired well in PP. I know what Ilja will say, but we tried different partners, coaching, basically everything and it just didn't improve. The others and particularly the junior developers thrived in it.

My two cents.

That correlates well with what I've seen. I also think that people just have different capacities, and different tolerance, for verbal interaction. It breaks somewhat along temperament lines (introverts do seem to have more trouble with it), but not strictly so. As I said before, I just feel like I'm thinking in a completely different way when I'm coding than I am when conversing with someone. Shifting back and forth between the two keeps me perpetually off-balance.

[Damon Black]

Originally posted by Ilja Preuss:
...I also wonder whether the team did iteration retrospectives where such issues where discussed openly.

I missed this comment earlier. We did, in fact, have weekly retrospectives. It was in these that I began openly doubting our company's dogma on XP. We had one the morning before I was fired.

Anyway, I'm beginning to see my dismissal as something long overdue. I need to get very far away from 'agile', especially 'XP', for a while.

I see a lot of good things in agile practice. TDD, 'simplest thing that could possibly work', short iterations, on-site customer - all these and more seem like practical, common-sense solutions. But I've grown very weary, and wary, of approaching these techniques as a means of 'revolutionizing software development'. I just want to write code. I'm not interested in political, or religious, devotion to any methodology, least of all one that insists that I must program in a way that directly impedes me.

[Gaurav Faujdar]

I feel that pair programming is about discussing and solving your problem together rather than only sitting together on a computer, where one person is typing away and the other is plainly watching.
Of course, once you have a algorithm for you problem there is hardly any point sitting together but when you are still in the primitive stages of your solution I have experienced that it helps if two people are sitting together and charting out a roadmap to solve it.
I am still a beginner in this field so pardon me if I dont get the hang of pair programming the way its meant to be.

[Saranyan Narayanan]

When there is knowledge level similar in pairs then it is fair to say it will work , for instance , if two senior Engineers sit together they could make sure that the code is discussed and then done.

If there is one of the engineers in the pair who needs to lead all the time because of experience , it is hand holding not pair programming

[Hedley Finger]

When you are really hot, in the zone, going with the flow, to have a partner interject to suggest another (not necessarily better) way of doing it completely derails the train of thought.

How do people on this topic who claim to be successfully using pair programming deal with the distraction factor?

[Hedley Finger]

Can anyone comment on the effect of XP/Agile development on the technical writers producing the user procedural and reference documentation? A programmer pair can make changes in an hour or so that takes the technical writer days or weeks to update in the documentation source.

This typically involves taking new screen shots, updating the reference material supporting those shots, adding new procedures, rewriting, moving content from one chapter to another, etc. Most documentation applications (Word, FrameMaker, etc.) produce binary files which cannot be merged so when major restructuring is required, one writer has to check out and own all the source and destination files to make the changes.

This situation is somewhat eased by using XML-based content management systemts for the doco source, which allow diffing and merging like code, but are not the complete answer.

Most discussion of XP/Agile focusses on developing functionality. But, hey, the on-line help, web interactive help and FAQs, and printed documentation are part of the product too! Do XP projects find themselves moving the release date because too many iterations mean that unfinished documentation is holding up release?

[Ilja Preuss]

Originally posted by Gaurav Faujdar:
I feel that pair programming is about discussing and solving your problem together rather than only sitting together on a computer, where one person is typing away and the other is plainly watching.

Exactly.

Of course, once you have a algorithm for you problem there is hardly any point sitting together

That's absolutely *not* my experience. There are still a lot of decisions to do when implementing an algorithm: implementation details, test cases, naming, what boundary conditions to consider etc. pp.

Other advantages of pair programming when implementing an already decided upon algorithm are increased discipline (for example for doing test driven development), catching subtle bugs such as off-by-one errors, and dispersion of knowledge.

[Dario Laverde]

Having tried it myself, I can say that it works only with two programmers are matched as follows: compatible socially, similar typing skills, no language barriers, no egos, and one is the junior (apprentice) and one is the senior (mentor) programmer. That's a lot to ask for and explains why it takes some strict Agile shops a very long time to find programmers.

Probability-wise it's not designed to work. And I'm afraid it's really more of an excuse for management to pair senior and junior programmers. If it's defined as such, i.e. telling the senior programmer that the job entails x number of hours mentoring ("paired programming") with another programmer then fine, but that's not the wisest use of a senior programmer.

In fact of you pair two senior level (seasoned gurus) together, you'll get less productivity than if they were to work separately.

It's an XP practice that should really be retired, as it really isn't agile (lower case agile).

-Dario

[john Lin]

>>In fact of you pair two senior level (seasoned gurus) together, you'll >>get less productivity than if they were to work separately.

I don't think so.

[Ilja Preuss]

Originally posted by Saranyan Narayanan:

If there is one of the engineers in the pair who needs to lead all the time because of experience , it is hand holding not pair programming

That depends very much on the social skills of the experienced engineer.

In a well-working pair, it will be much more like a mentoring session than a hand holding session.

It is also my experience that having to explain my thoughts to a less experienced developer forces me to better think through the problem and solution, helping me to get a more clear idea of what to do. It can also be quite embarrassing to notice what holes can be exposed in your expert thinking by an innocent question from a novice trying to understand your strange thoughts.

[Ilja Preuss]

By the way, the book "Pair Programming Illuminated" contains some quite good chapters on different kind of pairings (such as expert-expert, expert-novice etc. pp.).

[Ilja Preuss]

Originally posted by Hedley Finger:
When you are really hot, in the zone, going with the flow, to have a partner interject to suggest another (not necessarily better) way of doing it completely derails the train of thought.

How do people on this topic who claim to be successfully using pair programming deal with the distraction factor?

It is my experience that pair programming leads to a different kind of flow. In that kind of flow, you are really working as one pair, thinking together, not as two separate developers. You are in a continuous exchange of thoughts, taking suggestions from your partner as stimulation instead of interjection.

Another effect is that it becomes much harder to get distracted from outside the pair, and much easier to get back into the flow once you got distracted.

[fred rosenberger]

Originally posted by Saranyan Narayanan:
If there is one of the engineers in the pair who needs to lead all the time because of experience , it is hand holding not pair programming

I used to teach middle and high school math. I don't think there was a day that went by when a student didn't have some insight that I had never thought of before. I think the same would apply to pair programming.

[Mike Dawson]

It is my experience that pair programming leads to a different kind of flow. In that kind of flow, you are really working as one pair, thinking together, not as two separate developers. You are in a continuous exchange of thoughts, taking suggestions from your partner as stimulation instead of interjection.

I agree with Itya entirely. If done properly it brings a dynamic all of its own where you can learn.