I wouldn't consider the critique of extreme programming to be useful in general if all one remembers about it is the "most opposed" component (most programmers balk at pair programming; too much cowboy mentality). Personally, I remember the "test first" rule first, and, for now, it's made tne most difference. In any case, unless you are planning for XP to fail, get one or all three of the books.

If a complaint is that you can't stop and concentrate, this suggests both partners are doing the at keyboard role at the same time, and no one is doing the strategic, "big picture" role.

As to the partner compatibility thing, pairings are by no means permanent.

-- Anonymous, April 06, 2001

Answers

This is interesting because I actually remember another thing first. I remember putting more of the control back into the users hands in the form of the planning game and short iterations.

I don't feel that most projects adequately give control to what to implement over to their customers, so this sticks out to me first.

This may be that I was already buying into testing first from my experience before I had heard of XP and that I have always done some limited pair programming and it's always been positive.

Chris

-- Anonymous, April 09, 2001

I think PairProgramming is the most remembered thing about XP because it is most problematic an unusual. Our team did tried to adopt XP and it is almost year now since we started. We did not adopted everything yet, but we want to do this. But PairProgramming is really a hardest thing to adopt. There are definitely lot of issues ivolved:

1) It is hard to justify that Pair is doing more than 2 developers to customer or upper management.

2) Skills difference creates problems. While developer with lower skills learning much faster than alone, another developer can get upset quickly. I would suggest not to create a pair with big skill difference.

3) Personal issues. Some developers at my experience just can't work in pair all the time. And they not jerks, so they brings great value to the project. I personally had a team before we started XP, so we have to go with people we have already.

4) Developers must be trained to work in pair. It is not enough to ask for this. I did this and I was surprised that developers got it completely wrong. So I had to teach them step-by-step. That's why XP community have an example of pair work with dialogs and code examples. As a result I don't force pair programming at all now. But amasing thing - since then developers naturally tend to work in pairs while they do something complex or very critical. So currently our team about 50% or production code does in pairs. Probably this number will grow in time.

-- Anonymous, April 09, 2001