Myths About Xp

Subject: Re: Who dislikes XP, and why?

Shayne. Thank you for this post, I really appreciate it. Reading it gave me a good apprehension for what you dislike about XP, and also gave me a way to talk with you about it. I think you have some misconceptions about XP, but I also think I can understand where those misconceptions came from. With more communication like this, we may be able to come to a closer understanding, and appreciation of each other's views.

Comments inserted below.

On Sun, 09 Dec 2001 19:34:56 GMT, "Shayne Wissler" <thales000@yahoo.com> wrote:

XP Crushes Individuality 

 >But my approach has fundamental
 >differences with XP. Here is an incomplete list (perhaps one day I'll write
 >a more thorough one):
 >
 > - I believe that a division of labor is a good thing. Programmers should
 >have the opportunity to work on what type of thing they enjoy, and get good
 >at it. If someone loves GUI's, then they should be allowed to mainly do
 >GUI's. If they love interfacing to the database, then that's what they
 >should focus on. On the other hand, some people like getting their fingers
 >into everything, and they should be allowed to learn one area in detail, and
 >then another, but not all at once, not so they become familiar with all but
 >master of none (which is where bad architects come from). Or they should
 >perhaps work smaller projects.
 >
 >In general, people shouldn't be jumping around the system like butterflies;
 >for a certain time, they should specialize in an area.
XP allows you to spend at least half of your programming time in your specialty, if that is what you desire. Developers sign up for the tasks that they want to be responsible for. If they want to focus on a specialty, then they will sign up for tasks in that specialty.

XP also puts pressure on developers to spend about half their programming time pairing on other peoples tasks, so that they can get some familiarity with the other parts of the system. This promotes communication and understanding amongst the team; and spreads knowledge. It also makes the projects less vulnerable to the loss of a particular specialist.

Architecture Requires an Architect 

 > - A corollary of this is that I believe in having an architect, the person
 >who creates the division of labor. He should be someone who's been through
 >all the details and who keeps up on the technology, not an ivory-tower type.
 >He should care passionately about the overall integrity of the system, but
 >not disdain the details. He should care about maximizing every programmer's
 >efficiency, and be sensitive to decisions that impact their performance.
 >GradyBooch has given decent descriptions of this role.
Why do you think this is counter to XP? XP does not want ivory tower architects who produce documents and throw them over the wall to the developers. But XP has no problem with team members who are architecturally strong. A well formed team may indeed appoint someone to act as an architect to be responsible for the guiding vision of the system. XP teams do not require this role; but I have certainly seen XP teams where the role has been created out of need.

PairProgramming is a Crutch 

 > - Although I program side-by-side from time to time, especially when
 >mentoring or transferring information, I think that full-time
 >pair-programming is a disaster. It is the individual that is creative, not
 >the collective. Individuals need to learn to monitor themselves so they know
 >when to ask for help; they shouldn't have a crutch sitting next to them all
 >day just in case they forget and get stuck.
The rule in XP is that you cannot produce production code unless you are working with a pair partner. XP does not say that you must spend all your time bound to a pair partner. You can work alone any time you like. You can experiment vith various program structures, and write prototype code alone if you like. You can take as much time as you can afford to work along and be creative. You simply cannot type in production code alone.

Being Onsite wastes the Customer's Time 

 > - Although the customer priorities are #1 in the final analysis, they
 >shouldn't directly determine the day-to-day flow of events. The most crucial
 >part of a project is to identify the architecture. In my approach, it means
 >architecting and building a small scale version of the system that exercises
 >every key, difficult part of the system. The candidate requirements to be
 >implemented in the small scale system are selected on the principle of "what
 >is likely to invalidate my assumptions", not "what did the customer say was
 >the most important thing to him." (all things being equal, I select based on
 >customer importance, but I don't sacrifice the architecture for the sake of
 >impressing the customer in the short-term).
It is hard to conceive of something that would be architecturally important but not important to the customer. XP does not eschew architecture. Instead, XP creates architecture in the presence of rapid feedback while working on the features that have the most impact on the customer.

This seems an appropriate strategy for building an architecture. Rather than using brain power alone (not that brain power isn't important) we focus the architectural effort on those parts of the system that the customer feels are most valuable, and we create that architecture one small step at a time, verifying that it works at each small step.

At first the vision of the architecture is indistinct, because we do not have much data. But as iteration after iteration goes by, the data becomes clearer and clearer, and the appropriate architecture for the system becomes distinct.

Architecture Must Be Installed First 

 >Once the architecture is in place, then customer priorities start driving
 >the day-to-day, more like an XP project (particularly if we can get
 >incremental benefit from a partially completed system). But only after that
 >critical step is complete.
How do you know when that critical step is complete; and how do you know the result is accurate? What elements do you consider if not those that are important to the customer, and why?

Forced Documentation Helps Developing 

 >Like XP, I don't believe in a lot of up-front diagrams. For me, the initial,
 >skeletal system fills the role of detailed diagrams. On the other hand, ~20
 >well-written pages of documentation for a 100K line system *written near the
 >end of its development* can be invaluable. And the better the code, the less
 >documentation that's required--all things being equal, spend the money
 >cleaning up the code, and shrinking the documentation. But don't eliminate
 >it.
XP does not recommend the elimination of documentation. Nor does it recommend its creation. The expectation is that developers will produce the documentation they, or their customers, need; when that need comes to the fore. -- UncleBob

Does this kind of paradigmatic pep-talking ever make you think that maybe XpIsaCult?

Under PairProgramming is a Crutch, Sean mentions that, "It is the individual that is creative, not the collective." This couldn't be more contrary to my experience, both in software and otherwise. It has been especially clear to me when I've helped with theater and electromechanical sculpture projects; many of the most creative ideas have emerged during interaction between two or more people. -- WilliamPietri

William expresses an "EmergentDesign" point of view. The ultimate goal is that we "enable creativity", whether individuals have epiphanies, or whether the creativity emerges from collaboration. Then, we don't thwart expression of that creativity. Even if I think of a new gimmick for the database but I'm not The Database Guy. -- PhlIp

The professional XP mythographer DougRosenberg, who has refused invitations from RonJeffries to discuss the subject in person (what a way to validate your position!), will be spreading XP disinformation at the following conference:

http://cmp.bluedot.com/re/attendee/wsw_02/openPages/speakerPage.esp?speakerId=36556116

Follows is a list of his bullet items:

I believe that anyone who (unlike Doug) has actually WORKED ON an XP project knows the answers to these points already.

Think about it - would you take advice from me about how to perform open heart surgery if I admitted I only knew about the subject from reading a few magazines?

A better analogy would be to ask if one would accept the advice of a heart surgeon specialised in key hole surgery on the problems with open heart surgery.

I always wondered what it would be like to live thru one of the scientific revolutions that I'd heard about from history books. Times like when the Catholic Church would burn you alive for saying that planets went around the sun instead of the earth, or like when early engineers were learning to build airplanes and their detractors would say inane things like "If G*d meant men to fly He would have given us wings."

I just thought we could have gotten more sophisticated about it by now. -- PhlIp

This trend is as old as science itself (probably older), and is described in TheStructureOfScientificRevolutions. Those who have something to lose from the new paradigm are its most vocal opponents. Most often, what they have to lose is their prestige (from being well-known advocates of the current paradigm). DougRosenberg fits the bill quite well. He has his own competing methodology called IconixProcess, which is what his whole career is based on. If XP succeeds, he loses. He's pretty much bound to oppose it. See CritiqueOfXp.

What makes you think it is a zero sum games and that for XP to succeed, Iconix must fail? This type of attitude, that is the only legitimate game in town that is XP's biggest problem.

I dunno... seems to me XP must be doing really well, if we now have guys spreading disinformation at conferences. The other day, I was in Dymocks bookshop, and there was at least 4 (was it 5) XP books on the shelves. I felt odd about that, having learned all about it on Wiki 3 years ago. XP has grown up, I think. Seeing it get out in the world is like seeing your daughter go out on her first date. -- AlainPicard

Are the points listed above really idiotic? I think we should encourage such criticism of XP and certainly we should not imagine that the battle in favour of a certain methodology is won.

You only have to browse these Wiki pages to find development situations where XP has very limited usefulness (LargeScale, frameworks etc.) or where an XP customer is hard to find (OpenSource, COTS). These and other problems offer points of attack and possibilities for improvement and/or flexibility in XP.

I've enjoyed trying out XP over the past couple of years and I feel that there is no part of XP without value. However, if we start believing that XP is right for all development situations and completely without fault we will find ourselves replacing one bad methodology with yet another.

The best way to seek out the limitations of XP is to compare it with alternative approaches. This is made all the easier if there are people like Doug arguing passionately in favour of these approaches. -- ChrisSteinbach

I don't know. Have you read anything written by Doug? He's not just passionately for IconixProcess, it seems he's also passionately (and somewhat blindly) against anything XP. He thinks we're all a bunch of idiots for believing anything KentBeck says, regardless of whether it's worked for us or not. Critiquing, yes, we need that. But when you refuse to look at the facts and argue fairly, you're not a critic, you're just a heckler.

I've looked hard, but cannot find any examples of XP supporters conceding to any kind of constructive - let alone irrational - criticism of XP. The stock-in-trade response seems to be "if you tried it and failed, then you weren't doing it right". I'm getting a little frustrated with hearing this "if it doesn't work then it's not really XP" argument. Can anyone point me in the direction of examples (threads on newsgroups, Wikis etc) where XP has been criticised for some failing and as a result the method has been "refactored" to correct it? -- JasonGorman

I realize that it's overused, but does Ghandi's quote apply here?

>First they ignore you, then they laugh at you, then they fight you, then you win.

Sounds like we might be transitioning from the second to the third stage.

To quote Kent Beck: "XP is a starting line. It asks the question, 'How little can we do and still build great software?'" To do less is to threaten the ability to build good software. To do more could threaten the ability to work quickly and with little overhead. The question "how little can we do" is valid, but saying the above myths are' what XP is promoting is just lying.

CategoryXpCritique CategoryExtremeProgramming

EditText of this page (last edited September 4, 2008) or FindPage with title or text search