eXtreme Programming is not a silver bullet

by brian d foy

Related link: http://www.ddj.com/articles/2004/0405/

Matt Stephens and Doug Rosenberg (co-authors of eXtreme Programming Refactored: The Case Against XP) wrote "The Irony of Extreme Programming" for the latest Dr. Dobbs Journal (which you can also get online with a membership).

They point out some of the things that I have thought for a while: eXtreme Programming (XP) has a lot of nice ideas, and it mitigates some problems, but it is neither a religion or a cure-all. In fact, it can create some problems of its own if not used well.

I like that they step back from the hype to look at some of the problems. I think the programming world (or maybe just the world, unqualified) tends to get too caught up in using a particular process or technique, even if common sense says something else. I have often told those close to me that if they cannot criticize their favorite thing, they do not know it well enough.

They quote an email one of their readers sent them:

The pair programming is mind numbing. With this XP stuff, software development is no longer a professional occupation, it's just another type of assembly line work.

Different people have different ideas about that, and as I write this from Detroit, home of the Henry Ford Museum, I wonder if those great innovations I learned in elementary school, like division of labor and the assembly, caused the same reaction. I would certainly expect that demoting a master craftsman to the assembly line would cause some problems, so why do some shops insist on doing that to senior developers just so they can say they practice XP?


2004-04-19 16:36:23
Praising XP with Faint Damns

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.

2004-04-19 18:01:19
Praising XP with Faint Damns
No one is giving XP a two sentence dismissal. I, and th Dr. Dobbs Journal article, simply say we should also use common sense. I am not arguing against XP, only blind adherence to it.

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.

2004-04-19 18:26:33
Praising XP with Faint Damns

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.

2004-04-19 19:48:20
Praising XP with Faint Damns
I never said that pair programming demotes anyone. Indeed, only the quoted email mentions pair programming, and I comment on the emailer's reaction to pair programming. I said that demoting master craftmen to assembly line workers would cause problems. If a shop practices XP (not just pair programming) in a way that the programmers think that has happened, there is a problem, as the email (which is longer in the article) shows.

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.

2004-04-19 20:42:56
The real question
The real question isn't whether a master craftsman would be upset about being put on a production line, but why you believe that making developers do pair programming is equivalent to that.
2004-04-20 03:01:05
So what?!
eXtreme Programming is not a silver bullet

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

2004-04-20 05:27:56
Pair Programming is not XP

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.

2004-04-20 08:29:43
So what?!
Almost any process ends up as gospel for some people who want to implement it, and I have heard plenty of project managers say that XP was going to solve their problems.

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

2004-04-20 17:30:21
I found the book very disappointing
I've not got a subscription to Dr Dobbs, but I have read through their book and was very disappointed with it.

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.

2004-04-21 10:02:18
Another article
You might find Diana Larsen's article "Embracing Change: A Retrospective" interesting.
2004-04-26 07:56:17
Pair Programming and TDD
I find it interesting that, working in a decidedly non-XP shop (still using Oracle Forms 4.5!), as I read this I am sitting one desk away from a "pair programming" session that has been going for over a week now as they work on a really tough problem.

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.