eXtreme Programming is not a silver bullet

I'm puzzled about criticizing pair programming as "making expert programmers do assembly line tasks". The goal of pair programming is not to punish "expert" programmers. It's to review code for clarity, simplicity, and adherence to common coding guidelines, to spread the knowledge of the program between developers for the purposes of improving the quality of the code and the skills of the entire team.

I can imagine that some teams will have difficulty doing that well, but I can't imagine that they'd be effective with any other development method. Nor can I imagine a situation where the goals of pair programming are at odds with the goals of any serious software development team.

If your expert programmers object to spending time with all of your other programmers, how are the latter supposed to learn? (Do you want them to learn?) If your project has a lot of simple, boilerplate code, why not automate it and spend your time solving interesting problems?

I think XP is worth taking more seriously than a two-sentence dismissal. Then again, eXtreme Programming Refactored criticized XP rather ineffectually by writing silly song parodies. I'm not sure "argument by filk" is (or should be) an effective argument technique. Stephens and Rosenberg probably aren't the people to provide a well-reasoned critique.

The goal of pair programming is noble (and achievable), but it also has social and other productivity effects, and why shouldn't Stephens or Rosenbery or anyone else the people to provide a well-reasoned critique based on that?

One of the things that I object to, and the point of my weblog post, was that people are intolerant of criticism of XP as if it were religious dogma that only certain high priests were allowed to talk about.

I believe that is your intent, but the last paragraph of your weblog still puzzles me. It appears to say that pair programming demotes master crafstman to assembly line workers -- and it does so based on two lines quoted from an e-mail!

Granted, I really don't care for the metaphor of software development as manufacturing, but it's not clear that Stephens or Rosenberg actually tried XP before writing their book. I hope other people will recognize that that's not a recipe for a well-reasoned critique.

Software development is a human endevour, so we have to pay attention to the human aspects of it too, no matter which process we use. Different perspectives provide opportunities for improvement.

I don't think anyone in the XP community ever claimed that it was.

Pair programming is not XP. In fact, in many ways, the practices are not XP. The suggestions of the XP community are that you try all of the XP practices before you decide what is and is not for you. There are unexpected synergies. The article you cite is, as you say, based on their book where their key point seems to be that you can only do XP if you do all of the practices.

Forget for a minute whether or not that is true. Think about a nugget you may have gained from a greater experience that makes that experience worth it. A book you have read where a particular passage moved you or a trip you have taken where you only really remember one of the days. For me, there are many things about XP that I like, but Test Driven Design was life changing. It changed the way I code and it changed the quality of my code.

Pair programming is one of the XP practices. When I do it, I do think that it improves my work - but I don't do it that often because I usually am not working in a situation where I can. I've often viewed Pair programming as orthogonal to the other practices. It is important and valuable but whether or not you do it does not have impact on the other practices. TDD on the other hand makes refactoring safe. Other practices are tied together in interesting ways. Pair programming is a perpetual code review.

But XP is not the practices. XP is the values and the principles. Recently Erik Meade blogged about this. He wrote about a project he is on saying "worked better, development teams shared ideas and reused code. New teammebers commented on how quickly they were brought up to speed and could contribute. But they had to do all that, because everyone knows you can't do Xp with 250 people."

Kathy Sierra recently blogged on not being able to do pair programming. She distinguished between people who don't like to pair and people who couldn't pair. She tried it, found that it was something she could not do, and she wrote a thoughtfull piece about it. She understands that pairing is not just sitting at the same keyboard - that there is a dynamism etc. I do not

Word, vi, or emacs can not write words for me but they are tools that I can use to write. eXtreme Programming does not pretend to be a silver bullet. It is a set of values, principles, and practices that many have found useful.

It isn't necessarily what a community says, but what the public believes.

I've been taking up and agile approach based on XP for a couple of years now and, while largely impressed with the improvements, have encountered some problems. (e.g. incorporating some of the traditional practices of user-centred design into XP).

I was hoping the book would supply real world examples of areas where agile methods, and XP in particular, were problematical and (with any luck) some pointers to how to fix those holes.

What I found instead was a series of straw men being demolished. There were lots of "If you do Foo then things will go horribly wrong" when Foo would be something no XP practitioner would recommend. Unless you are already conversant with agile practices being done properly it's very hard to separate places where they're talking about XP practices and the places where they're talking about really bad misinterpretations of XP practices.

From what I have read by people who actually worked on the project their comments on the Chrysler C3 project are also fairly inaccurate.

There were a couple of interesting snippets in the book (there was a nice little bit on pairing in different work environments), but it came across as being written by people who either didn't really understand agile development methods, or were misrepresenting them for comic effect.

While this is pure conjecture on my part, not having read the article, from the "assembly line" comment I suspect the Dr Dobbs article contains more of the same. In my experience the agile methods are the ones that are promoting the programmer as craftsman, and it's the more traditional approaches that reek of the assembly line. This sounds like somebody doing something that is being called "pair programming", but doesn't bear much relation to the XP practice.

In my opinion a much better read on some of the issues with XP and other agile methods is Barry Boehm and Richard Turner's "Balancing Agility and Discipline". While I don't agree with all of the conclusions in the book it is at least cogently argued.

Of course, one could make the argument that with Oracle 4.5 you need pair programming... ;)

On TDD, I too have been changed by Test-Driven Development. Shortly after arriving at my new job I wrote an app in .NET and introduced the shop to the concepts. It surprised some of the folks that I was able to refactor the code in ways they would normally be afraid to, thanks to the "safety net" feature of TDD.

All of this done without ever (formally or consciously) "adopting" XP.