blog of Kathy - Pair Programming is NOT always a choice

[Pradeep bhatt]

TWO programmers working side-by-side, collaborating on the same design, algorithm, code or test

Does the above definition apply to documentation ?.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
Is there any name for programming where three or more get involved?

We once did quadruple programming for an hour on a team - not because the task was that hard, but to settle a conflict.

The problem with more than two people is thaz it's virtually impossible to have them be equals - one will sit farther away from the monitor, or will feel excluded from a passionate discussion between the others. It easily becomes complicated, boring and/or unsatisfactory.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
Does the above definition apply to documentation ?.

No. That doesn't mean that writing documentation in a pair is a bad idea, though.

[Pradeep bhatt]

one will sit farther away from the monitor, or will feel excluded from a passionate discussion between the others.

This could be held in a bigger room with a projector? This will make sure that people are not left out and they can take turn in using keyboard/mouse etc.

[Pradeep bhatt]

Originally posted by Ilja Preuss:


No. That doesn't mean that writing documentation in a pair is a bad idea, though.

Thanks Ilja . Why are documents excluded from pair programming?

[Lasse Koskela]

Originally posted by Pradeep Bhat:
Does the above definition apply to documentation ?.

Well, I doubt that too many are pair documenting today but it might be worth experimenting. I know for a fact that most documentation I've seen has been next to worthless and that lack of discipline and boredom are large factors in the documentation getting that way. Pairing on writing documentation just might help alleviate those problems.

Then again, if the only reason you're writing those documents is to satisfy a corporate mandate, you might be better off just writing anything as fast as you can and forget about the quality. That is, assuming that those documents aren't really needed by anyone.

[Pradeep bhatt]

Thanks Lasse

Most of documents are not read by anyone.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
Who decides who should pair up ? :roll:

The team.

One way to do this is by a Stand Up Meeting. It is held in the morning to shortly discuss what was done yesterday and what is planned for today.

This is also made easier when the whole team sits in one room - than during the day you can just ask into the room wether someone would switch partner with you.

I've also heard of a team that uses an alarm-clock. Every pair works together for 55 minutes, then they have a 5 minute break and switch partners.

In the first days, it might be a good idea to encourage the team to build many different combinations of pairs - for example by using a BVC: http://www.bigvisiblecharts.com/000004.html

[Pradeep bhatt]

In the first days, it might be a good idea to encourage the team to build many different combinations of pairs - for example by using a BVC: http://www.bigvisiblecharts.com/000004.html

This is a good idea. Otherwise, people will stick to a same pertner all the time.

[Pradeep bhatt]

I've also heard of a team that uses an alarm-clock. Every pair works together for 55 minutes, then they have a 5 minute break and switch partners.

55 minutes? That will mean a person will work x things per day, each thing for 55 minutes. I feel he/she will not do justice to the job.

[Ilja Preuss]

Originally posted by Sonny Gill:
What I meant there was that if the skill levels are comparable, they will get more overall benefit from pairing up.

And I don't think that is true. I don't even think that sentence makes much sense. There are so many skills necessary for software development that I can't believe anyone can be worse than me in all of them. Perhaps I'm a great Java developer and know JAXB better than you - but you could still be better than me in finding good names or seeing duplication, for example.

Additionally, even *if* you were, even if you only force me to explain my thoughts to you, that can already be a great help. Did you ever try to find a bug for hours, and when you tried to explain the problem to someone else, it suddenly became all clear - just because it forced you to think differently about the problem?

And last but not least, if you are working alone you need to split your attention between tactical thoughts (how do I name that variable, do I use a for- or while-loop) and strategical thoughts (how does the new code fit into the overall design, how much of the feature is now working and what needs still to be done). Programming Pairs often find that one of them concentrates on the tactical (most often the one on the keyboard) and the other on the strategical issues - and that this simplifies their work.

"The whole is more than the sum of its parts" - I think that is very true for PP.

unless the objective was to teach the other person in sort of a master-apprentice arrangement.

That is, of course, one of the advantages of PP. And many "masters" find that they, too, can still learn interesting things from their apprentices.

I am not saying that there wont be any benefit, but will the benefit justify the cost?
There is, I suppose, no definite answer to that, and it has to be decided on a case by case basis.

That's true. And I would add that you should have tried it for a reasonable amount of time before you cann decide reasonably.

Ilja, what criteria would you apply to decide which 80% of the code to choose for PP?

Gut feel.

Also notice that I referred to an amount of time, not code.

For example I could already start a task alone, and you join me when you finished the task you are already pairing on with someone else. Or you are a late riser and join me when you arive...

[Ilja Preuss]

Originally posted by Pradeep Bhat:


55 minutes? That will mean a person will work x things per day, each thing for 55 minutes. I feel he/she will not do justice to the job.

Well, typically you have one person working on a task from beginning to end, and the partner switching regularly.

As a result, you have one person with the knowledge of how all the things fit together, and a partner with a fresh mind and new ideas every hour!

[Ilja Preuss]

Originally posted by Pradeep Bhat:
Why are documents excluded from pair programming?

I think the simple reason is that the need for documentation is very different between projects - but every software development project needs to produce high quality code.

And for a team that's used to PP, thinking of pair documenting if they experience problems in that area really should be a no-brainer...

[Dmitry Melnik]

I wonder, if I had a split personality, would I be able to work alone, and practice PP the same time?

[Carol Enderlin]

Originally posted by Pradeep Bhat:

Does the above definition apply to documentation ?.

Originally posted by Ilja Preuss:

No. That doesn't mean that writing documentation in a pair is a bad idea, though.

I found a reference to Writing In Pairs.
[ October 07, 2004: Message edited by: Carol Enderlin ]

[Lasse Koskela]

Originally posted by Ilja Preuss:
Well, typically you have one person working on a task from beginning to end, and the partner switching regularly.

As a result, you have one person with the knowledge of how all the things fit together, and a partner with a fresh mind and new ideas every hour!

Ilja, have you had the lurking problem of having the team split to the "regulars" and the "guest stars", meaning that some people tend to sit in the same place all the time and only a part of the team are switching *places* in addition to partners? Do you feel the need to give explicit attention to preventing that from happening?

I haven't seen such a habit realizing into a real problem, but I've often thought about it while waiting for the coffee machine.

[Ilja Preuss]

Originally posted by Lasse Koskela:

Ilja, have you had the lurking problem of having the team split to the "regulars" and the "guest stars", meaning that some people tend to sit in the same place all the time and only a part of the team are switching *places* in addition to partners? Do you feel the need to give explicit attention to preventing that from happening?

I haven't noticed such a problem yet, and I'm not sure wether it actually needed to be a problem. Some people might like to switch from task to task, while others might prefer a little bit more continuity. As long as that upsets noone...

[Jeff Langr]

Originally posted by Ilja Preuss:
Well, typically you have one person working on a task from beginning to end, and the partner switching regularly.

As a result, you have one person with the knowledge of how all the things fit together, and a partner with a fresh mind and new ideas every hour!

What Ilja points out suggests one of the many "hidden" benefits of pairing.

Context-switching is difficult, as one of the other posters suggested. Work for only 55 minutes then switch tasks? Seems outrageous. It'll take almost that amount of time for me to come up to speed on what you've developed in the past few hours!

One XP rule of thumb is: when something is difficult or painful, do it more often until it becomes easier. If integrating is a royal pain, do it more often until we learn how to do it better, or at least until it's apparent we've hit the point of diminishing returns. Hence tools like Cruise Control.

If context-switching takes too much time, do it more often. What this should do in theory is to get developers to write better code. By "better" I mean code that accommodates cheap maintenance without adverse impacts on the system.

If it takes me 30 minutes to come up to speed on a task, yeah, we have a thrashing problem. If instead I follow good design/coding guidelines (small, composed methods, no duplication, appropriate naming, and basic OO design principles go a long way), context switching can take only a couple minutes. Couple that with a test-driven approach, and the new developer can quickly focus in on a small amount of detail.

-Jeff-
[ October 07, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

As far as mandating pairing, I agree with Ms Sierra's contention that it's not for everybody.

At a large XP shop of ~300 developers, about 15 (5%) actively resisted pairing. The rest of the people fell into one of three groups: skeptics, interested adopters, and cows, often divided fairly evenly.

After doing it for a while, perhaps 5 resisters learned to enjoy it, another 5 didn't mind it enough to complain any more, and another 5 hated it even more than before. The numbers are small and pretty consistent from shop to shop. Based on what I've seen, you'll end up with from 1 to 5 percent of developers who can't or won't pair. For most shops, that's one or two people.

(Obviously there are always people who don't voice their objection and just go along with whatever is tossed their way. You do want to ensure everyone has a forum for feedback. We solicited feedback via anonymous 3x5 cards, email, public forums, one-on-one discussions, however we could. Beyond that, if someone isn't going to be honest enough to complain, I suspect it says something about the caliber of that employee.)

Ms Sierra asks what WE would do with these people, with her.

First, it's a failure if we can't turn some people around. Any shop embarking on XP, RUP, Scrum, or whatever, needs a coach that helps accomplish this. Engaging in a new process without a coach is worse than trying to play a football game without a coach--at least the football players have done it all before and know some of the things to watch for.

Second, most shops do not mandate 100% pairing. That's very rare. As Ilja (or was it Lasse?) mentioned, 80% is a good number for him. It's a good number for most of us, myself included.

Most sizeable shops have small adjunct efforts. For valuable resources such as a Ms Sierra, one-offs are a great place. I'd also be willing to work with a diminished pairing role on a team if the employee and team was willing to put up with their end of the bargain. Remember that pairing is initially a way of doing continuous review. In lieu of pairing, we do Fagan inspections or some other sort of formal review. One way or another, the code must be reviewed--otherwise we get pricy consultants like myself, or unguided novices, producing unmaintainable garbage. Often, people find that the evil of pairing is preferable to the evil of group review.

Ultimately it should be a team decision. If the entire team revolts and insists upon no pairing, then we all do inspections or whatever review form acts as a second-best choice. If 95% of the team insists upon it, and the sole remaining developer can't do it, we help them find something else in the organization if possible.

Let me turn the question around. I go to your shop and find out that you value RAD. You sit in a board room with 25 other people for two days and hash out every detail of the project. You then produce 200 pages of design documents. I have a personality disorder that prevents me from making a valuable contribution in such a large group. I can't stand sitting in a room for days on end slogging through stuff, 95% of which is useless to my role. I also have a personality disorder that prevents me from understanding design document doublespeak.

Do I belong in this organization?

I'm not trying to be clever or obtuse here. The point is that organizations should grow the cultures that they value, and that those cultures may not be appropriate for everyone. Anyone who says every shop should do XP or RUP or whatever is insane. The reality is that there are always other shops to choose from.

-Jeff-
[ October 07, 2004: Message edited by: Jeff Langr ]

[Jeff Langr]

Pairing exists largely as a form of continuous review. It also should produce improved designs (or improved realizations of preconceived designs) and higher code quality (lower defects). Simple reason, two heads are better than one (three can be a crowd, though).

Here are some lists of benefits:

General:

Better coverage on code. By switching pairs, developers understand more of the system. Many benefits can result from this increased knowledge.

Minimized dependencies upon personnel. Worry less about buses.

Results in a more evenly paced, sustainable development rhythm.

Can produce solutions more rapidly.

Team members rise to a higher level (i.e. the lowest common denominator) of skills and system understanding.

Helps build a true team.

Specific benefits from a management standpoint:

Reduces risk

Smaller learning curve for new hires

Can be used as interviewing criteria ("can we work with this guy?")

Problems are far less hidden

Helps ensure adherence to standards

Resource fluidity

Cross-pollination. Allows you to swap members from two or more teams on occasion, with minimal downtime. Usually each person will bring immediate value to the new team ("you guys should use this utility class that we built here...").

Specific benefits from an employee perspective:

Awareness of other parts of the system

Resume building

Decreased time in meetings

Continuous education. As someone who thinks he is a pretty hot programmer, I still learn new things every day from even the most junior programmers.

Ability to move between teams. ("this team is boring," "I can't stand working with him," "that stuff they're doing looks cool."). Since this can be a benefit for mgmt as well, they don't have to clamp down on their resources.

More rapid learning as a new hire. You don't sit and read out-of-date manuals for a week, or worry that you're going to be fired because the system looks indecipherable.

Note of course that these benefits come about from monitoring the process, making sure the technique is executed well, and fixing problems. Don't forget a coach!

-Jeff-
[ October 07, 2004: Message edited by: Jeff Langr ]

[Sonny Gill]

Hi Ilja,

Originally posted by Ilja Preuss:
Originally posted by Sonny Gill:
What I meant there was that if the skill levels are comparable, they will get more overall benefit from pairing up.


I don't even think that sentence makes much sense

I think it does, in the context of the rest of my post
I meant to compare the benefits of pair programming in those two different scenarios - 1) comparable skill levels, and 2) big gap in skill levels

But trivialties aside, thanks for clearing up a lot of things about PP for me, I only had a vague idea about it before this.

cheers mate.

Sonny.

[Sonny Gill]

Very informative and helpful posts, Jeff.
Especially the need to have someone who can coach a team properly into the use of new practices.

Thanks
Sonny

[Warren Dew]

Jeff Langr:

Do I belong in this organization?

I'm not trying to be clever or obtuse here. The point is that organizations should grow the cultures that they value, and that those cultures may not be appropriate for everyone. Anyone who says every shop should do XP or RUP or whatever is insane. The reality is that there are always other shops to choose from.

Yes.

I think it would be an interesting exercise to think about what kind of organization would work best for loners. One possibility might be a distributed team, with each person working from his or her own location. Code inspections or reviews might be done by email.

[Surasak Leenapongpanit]

Originally posted by Pradeep Bhat:
Is there any name for programming where three or more get involved?

Pair Programming Variations And Alternatives

[Pradeep bhatt]

In many situations, the paired programmer need not be programming literate, but problem domain literate. Having the domain expert sitting alongside, the programmer can question the expert immediately regarding something that comes up but isn't apparent until the code itself is being written. To answer several "what if" situations. As a corollary, the expert can have the programmer explain what is being done, and comment on whether the programmer is going down the correct path or has perhaps made a wrong assumption.

I was involved in triplet documenting yesterday. It was a quite useful experience.

[Jeff Langr]

Originally posted by Sonny Gill:
I meant to compare the benefits of pair programming in those two different scenarios - 1) comparable skill levels, and 2) big gap in skill levels

With pairing, not only are there issues with respect to skill levels, but also with respect to personality types (introvert and extrovert).

As far as the skill level gap: An experienced developer can outperform an inexperienced developer by two, three, five, ten or even twenty times. So sitting with a novice can be excruciatingly painful. But for me, I'd rather burn a little time bringing other guys up to speed as soon as possible.

Pairing allows me to keep tabs on their work and make sure they are not producing junk that will have to be rewritten. It also prevents them from holding up the project. Several years ago I was on a project that ultimately got cancelled, largely due to a schmuck that couldn't get his work done in time, and when it did get done, it was garbage. With a pair, incompetence that can destroy a project surfaces far more quickly.

Also, I mentioned in an earlier post that I still learn some very interesting things from working with novice developers. And they learn a wealth of things that they would never learn were they to be left to their own devices.

Leaving an inexperienced developer alone to suffer through the system and other issues presents them with a steep learning curve. Through pairing, this learning curve begins to flatten more early on in the project. The more time I spend up front with a novice developer, the more we can depend upon their contributions later in the project--when it matters far more.

Note that this of course depends upon the novice being someone who is capable of growing. Pairing lets you find out quickly who's worth keeping on the team versus who will always be a drag on the team. Management can get involved in the first month or so of a project, as opposed to late in the project when it's crisis time.

-Jeff-

[Kathy Sierra]

Originally posted by Jeff Langr:
The point is that organizations should grow the cultures that they value, and that those cultures may not be appropriate for everyone. Anyone who says every shop should do XP or RUP or whatever is insane. The reality is that there are always other shops to choose from.

I would have quoted your entire message, but it was too long to repeat. I liked ALL OF IT! It was the most reasoned response I've heard--extolling the virtues but still being realistic and practical without serious evidence of "drinking the koolaid" .

The paragraph above is my favorite, though, because I think the culture point is really valid. And I don't believe a company should go waaaay out of the way to accommodate the one person that wants to do pairing no more than, say, 25% when literally everyone else wants to do 80%. And while I'd *hope* that the company could still find something where that person could thrive, it simply might not work out well, and I don't believe the company should go to extraordinary measures to provide for one person.

And I believe that it's the responsibility of that one (or very small number) to help come up with things they *can* do if they are not willing (or in my case, *able*) to go down that road. Of course I don't believe that I have a personality "defect"--but being in the minority with my psychological makeup does mean that I need to be more proactive at finding things where my abilities can be exploited, without making myself (and others) desperately uncomfortable.

Anyway, Jeff, I really appreciated your comments. Makes a lot of sense, and you got me to think about things just a little differently. If I were to speak to the other *true* loners, I guess I'd suggest that in a pairing shop, assuming you've really seriously tried it and discovered you can't (without great personal cost), you should take responsibility to pitch your employers on things you *can* do, that would be of great benefit to the team. In other words, if the culture of your team wants to be heavy into pairing, it is probably not their responsibility to find something for you--YOU have to make that happen. A good manager will want to listen, and want to make use of your talents and skills in some other way, if it works out... otherwise, you need to look for a shop with a different culture, or do something different.

cheers,
Kathy

[Jeff Langr]

Thanks for the note Ms Sierra!

One more comment: I've been in the position of promoting XP and hence pairing as a consultant for a while now. Until I did a longer stint last year (7 months), my pairing experience was more sporadic. Sure, I saw the benefits and the negatives, and did it enough to know how to make it work. Plus I learned plenty more about it from other sources. But until I sat there and actively did pairing for a longer duration, some of its nuances weren't as evident.

In fact, pairing seemed to me like a nice thing to promote, but maybe pairing wasn't something that I needed to worry so much about. Not drinking my own kool-aid!

What I realized is that pairing after a while becomes a dependency, in both a good way and a bad way. I learned to look forward to most pairing sessions (there are always some difficult people). I also felt naked when not pairing, and begin to question more what I produced by my lonesome self. Pairing became assuring and thus relaxing.

Before, I would be overly confident that I was a great programmer and that I produced code that was just fine. Maybe not! A few pairings with some sharp people and I learned a few cool new techniques. I took on more humility.

Dependencies in code can be bad, as can dependencies in life. The secret is in managing these dependencies well. Learn to use pairing as a tool to help you do better the next time you aren't.

-Jeff-

[Jeroen Wenting]

When I joined the team three years ago, he would typically get his assignment, look at a blank wall for 3 hours, and then code the solution. Getting him to even notice you while he concentrated required a whole lot of effort. We PP'ed a little bit to get me up to speed, but it certainly wasn't easy and didn't stick as a practice.[/qoute]

sounds like me. Once I really get into coding you can shoot of a gun next to my head and I won't notice.
I also tend to loose track of time. More than once I've been brought out of a coding frenzy after 10 hours or so only because I got seriously hungry.

[Jeroen Wenting]

Originally posted by U Patel:
if a piece of work is being designed by two developer or team will be much more effective than looking at the code over the shoulder.
--------------------------------------------------------------------------------



PP is *not at all* about "looking over someones shoulder". That's a very common misconception.

It's very common practice though.
Even a book about XP by Kent Beck himself that I read mentions it specifically.
One person writes the code while the other looks and intervenes when he sees things go in the wrong direction.
That's specifically what Kent wrote to describe pair programming, and he more or less invented the practice as relates to XP...

I am lucky enough to have a very good friend working with me in the team. After PP'ing for two consecutive weeks, we recently were on the brink to killing each other.

That's one of the reasons most teams prefer to switch partners several times a day.

which soon gets impractical as PP/XP has been marketed as mainly profitable for small teams...
For example in our team we have 3 Java people, switching partners there would be kinda tough.

We share code, work together on problems. But each of us has his own desk and screen and will typically use that.
If needed we move over to each other to work on something together for a few minutes, but forcibly working together on the same piece of code constantly (or even most of the time) just won't work for us.
We're too much individuals.

Which brings out the crux: while PP might work for proverbial interchangable code monkeys, and for solving difficult problems together that take more than each single person in a team can do on his own, overall it tends to constrain the creativity of the people involved.

[Ilja Preuss]

Originally posted by Jeroen Wenting:
For example in our team we have 3 Java people, switching partners there would be kinda tough.

Would it? Why? We are doing it on a four people team, and it works just well.

A common misconception is that you can only swap partners at task boundaries. But once you get used to it, it actually is quite effective to switch them mid-task!

forcibly working together on the same piece of code constantly (or even most of the time) just won't work for us.
We're too much individuals.

Well, *forcing* would work for noone. *Deciding* to try it for a short amount of time (say, a week) just to see what happens might be interesting, though. Being an individual actually isn't that much of a problem, in my experience (given there is enough respect between the team members).

Which brings out the crux: while PP might work for proverbial interchangable code monkeys, and for solving difficult problems together that take more than each single person in a team can do on his own, overall it tends to constrain the creativity of the people involved.

Constrain creativity??? How would that happen???

[Lasse Koskela]

Originally posted by Jeroen Wenting:
While PP might work for proverbial interchangable code monkeys, and for solving difficult problems together that take more than each single person in a team can do on his own, overall it tends to constrain the creativity of the people involved.

Do remember that pair programming is not about solving more difficult problems than what each developer can solve by themselves.

[Ilja Preuss]

Originally posted by Jeroen Wenting:
Even a book about XP by Kent Beck himself that I read mentions it specifically.
One person writes the code while the other looks and intervenes when he sees things go in the wrong direction.
That's specifically what Kent wrote to describe pair programming, and he more or less invented the practice as relates to XP...

Well, my German copy of the white book contains the following about PP:

(pg. 100, roughly translated back into english by me)
"Pair Programming doesn't mean that one person programs, while the other watches. ... Pair Programming is a dialog between to developers, who try to program (and analyze, design and test) together, and to learn how to improve. It is an conversation happening on many levels, which is aided by a computer, and focused on a computer."

[Dan Johnsson]

Originally posted by Linda Rising:
There are so many principles of XP or the other Agile Methods whose goal it is to get us to work well together. PP is probably at the top of that list. I'm not sure it's necessary to adopt this practice if it doesn't work well for you *and* if you communicate with your team members and do some kind of code review./.../

In my opinion, the fast feedback cylcle is the heart of pair programming. I e feedback cycle taken to its extreme (hence the name of the process).

However, another of the agile core values are Adaption; to constantly modify your tools and processes to get a better performance.

So having a fast feedback cycle by sitting a meter from a collegue, who you constantly exchange id�as with, is not pair programming in letter, but well in spirit.

[Jeanne Boyarsky]

We are doing it on a four people team, and it works just well.

Ilja,
How do you handle vacation days, meetings, etc? In other words, do you end up programming individually when an odd number of people are around?

[Ilja Preuss]

Originally posted by Dan Johnsson:

So having a fast feedback cycle by sitting a meter from a collegue, who you constantly exchange id�as with, is not pair programming in letter, but well in spirit.

Well, it isn't the worst thing to do, but in my experience it's also far from being as effective as real Pair Programming.

[Ilja Preuss]

Originally posted by Jeanne Boyarsky:

Ilja,
How do you handle vacation days, meetings, etc? In other words, do you end up programming individually when an odd number of people are around?

Well, yes. We don't do 100% PP anyway, even with an even number of people around, though the PP quota is rising. Two weeks ago we had a very stressfull week with a tight, critical deadline, in which we ended up approximately 90% PPing. Otherwise it's probably more around 70%, currently.

[Jeff Langr]

Here are the rules I promote:

If you have an occasionally odd number of developers, non-pairing developers can do several things:

- work on the acceptance test framework, work on other tools, work on the build scripts, etc. I.e., non-production code. In most shops, these are in dire need of attention.
- work on documentation
- work on spikes for future stories
- learn how to use a new third-party product; learn a new coding technique; and so on
- identify problem spots in the production code that need refactoring
- refactor tests / improve the existing test coverage if necessary

Any of the above could be done better if a pair were available, but they are hopefully lower risk activities. If time is absolutely a factor, the non-pairing developer can work on production code, but with the insistence that such code is peer-reviewed after the fact.

Having a non-pairing developer work on production code should be the exception, not the rule. As such, it should be justified and treated as a high risk activity.

-Jeff-
[ January 04, 2005: Message edited by: Jeff Langr ]

[Santosh Ramachandrula]

From my experience I prefer pair programming (I would call it pair DEBUGGING)only if I am debugging something and I am not able to resolve it for a long time.

With all the Java/J2EE coding practices around I really do not see pair programming as an effective tool in development phase.

[Ilja Preuss]

Originally posted by Santosh Ram:
From my experience I prefer pair programming (I would call it pair DEBUGGING)only if I am debugging something and I am not able to resolve it for a long time.

With all the Java/J2EE coding practices around I really do not see pair programming as an effective tool in development phase.

That's interesting. How long did you try Pair Programming (for not just debugging) and what was your experience? In which way do you think do other coding practices make PP an ineffective tool? What do you exactly mean by the "development phase"?

Thanks!