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?
11 Comments
chromatic 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. |
brian_d_foy 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.
|
chromatic 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. |
brian_d_foy 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.
|
tom_davies 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. |
otto 2004-04-20 03:01:05 |
So what?! eXtreme Programming is not a silver bullet
|
dsteinberg 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. |
brian_d_foy 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.
|
adrianh 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.
|
adrianh 2004-04-21 10:02:18 |
Another article You might find Diana Larsen's article "Embracing Change: A Retrospective" interesting. |
sgtrock 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.
|