Critique Of Xp

KendallScott? and DougRosenberg provide a critique of XP at http://www.ratio.co.uk.

Download ObjectiveView issue #3 (http://www.ratio.co.uk/ov3pdf.zip), and see pages 16 thru 22, "XP: Cutting Through the Hype" - "Doug Rosenberg and Kendall Scott put the counter arguments to XP." This is an anti-ExtremeProgramming article, following a relatively pro-ExtremeProgramming article (http://ootips.org/xp.html) on pages 10 thru 15, " Extreme Programming A Lightweight OO Development Process" - "YonatSharon summarizes KentBeck's Extreme Programming, - using his own words" (with references to Wiki pages).

In response, here's what seems flawed about SmartProgrammers (SP), the authors development process.

How often do you really get to hire the top 5% of anything, let alone precious software developers? ExtremeProgramming is designed for normal people (like me), not just those with 400 pound brains.

When is the last time you found a qualified architect? ExtremeProgramming does not require this. It just takes a few people with some ideas to develop a system.

Why not take to time to understand architecture? Quite frankly, engineering approaches like RUP were designed to used by most software practitioners, not just the top 5%. And scalability is built in. Sure, XP might be appropriate for small projects, which are the most common, but medium and large projects, with changing users, analysts, and developers, require a more systematic understanding and knowledge capture of the problem space, the solution space, and, most importantly, the relationship between the two. -- Will Stewart

Let's look at the RatioClosingQuestion from the critique.

They didn't post their process to an open forum, like the Wiki, for public critique.

It's unfortunate that they didn't have a chance to read YonatSharon's paper from the same issue of ObjectiveView before writing theirs. Today's readers should read Yonat's first, then Rosenberg/Scott, and draw their own conclusions whether the two papers are discussing the same subject.

They read the paper, all right. Everything there came from a couple of weeks of heated email exchanges on the OTUG mailing list. Rosenberg's universe and mine do not coincide much or often. We have great difficulty communicating with each other. -- KentBeck

Speaking as one who was present during the debates on OTUG, I'm inclined to agree with Kent here. For those who want to see it themselves, go to the OTUG mailing list archives at http://www.rational.com/support/usergroups/rose/otug.jsp [fixed link] and browse the archives by subject (or by thread) for Feb'99 and March'99. Look for the following keywords in the subject-lines: "XP", "Courage", "Aggressive", "Knowledge in tests", "Mix and Match", "Pair Programming", "Ready/Fire/Aim", "Refactoring", and "Systematic Review" -- BradAppleton

It seems to me that the disagreement is smaller than the ExtremeMisunderstanding. --YonatSharon

From amazon.com:

Doug Rosenberg's own review of their book: "About a year and a half ago, I met Kendall Scott, who was looking for his next project after winning every award in sight with UML Distilled, and we decided it was time to answer the question in book form."

The listing for the book in question:

 ISBN  0201325632 
 Uml Distilled : Applying the Standard Object Modeling Language
 (Addison-Wesley Object Technology Series) 
 by Martin Fowler, Kendall Scott (Contributor), Ivar Jacobson

SP is not intended to be a defensible methodology. It is a rhetorical device, and a damned clever one at that. Attacking it plays the game of the authors.

I'd like to play their game for a moment. Here is SP as they present it:

Hire only the top 5% performers that are personally known to you, or referred by a top 5%er that you trust.
Have a chief architect plan the software architecture very carefully, such that there is minimal coupling between work units (say, UML packages).
Have the chief architect match the work units to the specific skill sets and experience of the SP staff.
Have all of your SP programmers work from home, where they will not be disturbed, unless they explicitly request to work in a common facility.
Limit status reports to half a page, sent via E-mail, once a week.
Have your SPers bring in incremental builds for testing when they decide they are ready.
Restrict communication between SP developers to E-mail and phone, on an as-needed basis. Never bring all of the programmers into the same room at the same time except during integration testing, and then only those whose code is directly involved.

Now, I've seen this work too, but with two additional elements:

A clear and unifying vision.
High motivation of all involved.

Take these two elements away, and the whole thing collapses.

Without the unifying vision, no architect can keep the all the distributed developers on the same track. Worse, the top 5% are usually very creative people that can easily take opposite directions without a clear vision to keep their work coherent.

The motivation may be even more important. I've seen projects run on pure motivation - no special skill, no process, no clear requirements - just high motivation. And it works. Whenever I've seen SP works was when there was high motivation, a feeling of a joint adventure with a cool gang and high rewards at the end. Kind of like D&D in real life.

--YonatSharon

As someone said earlier SP is not a real suggestion. The authors in question present it such that they can then claim it will have the same properties that XP has. They then tear them both down together. They claim SP will not scale therefore, even though XP and SP have nothing in common, XP will not scale either. It is much more subtle than the other example when they refer to a project which has nothing to do with XP what so ever. It was just some project that did not use their methodology. It produced some questionable code and therefore XP will also. They must think we are all idiots. The real message of this article is to use their own methodology, which is not free like XP; you must buy their book. -- DonWells

Of course a process very like SP scales superbly, they developed the Linux kernel that way. You just let the developers self select, don't use the phone, integrate as often as possible and throw several thousand motivated user/testers at it ;-) -- TomAyerst

I read the two articles. Yonat, nice compilation job! Rosenberg and Scott may have legitimate objections/arguments to make with respect to XP, but that fact wasn't much demonstrated in their article. The central thesis seems to be that:

a) fans of XP annoy Rosenberg and Scott

therefore,

 b)Xp sucks.

I'm sympathetic to this kind of thinking. (Nascar, anyone?) But it's not the kind of thinking that gives me confidence in the analysis skills their article emphasizes.

At any rate, as an aside: Imagine my surprise and delight to see that I had contributed three paragraphs to the articles! Wiki is so cool. I love it here. -- MichaelHill

"Most ignorance is vincible ignorance. We don't know because we don't want to know." -- AldousHuxley

It's not up at the web site yet but ObjectiveView #5, pp 35-38 has an article called Goldilocks and the Three Software Processes by DougRosenberg and Kendall Scott which simultaneously bashes RUP and XP in order to show why their ICONIX Unified Process is the best.

I found it to be yet another poor form article that has to revert to mud-slinging and misrepresentation in order to sell their own agenda. --JasonYip

Yes, they are indeed at it again. Personally, I found their claim that you must lower your consumption of unsaturated fats in order to be a successful programmer a bit strange! -- DonWells

I think it's great! It reminds me of those caricatures of Darwin (with an ape body) before everyone realized how right he was. The fact that XP is growing despite these attacks points to just how weak the attacks are, and in my mind it strengthens the case for XP. I'm going to go out an buy their book now, just so I don't feel like a hypocrite when I start criticizing it! :-) -- RobHarwood (who thinks the analogy to a KuhnParadigmShift is 100% on the money)

A truly cringeworthy article! Anyway, Rosenberg seems to have misunderstood a key point of the story in that in each case, porridge bowl, chair and bed, Goldilocks finds that the *smallest* is 'just right'. As Rosenberg equates XP with the smallest, he's really just saying that XP is the best process! He must have (subliminally?) realised this as I gather he's now making Iconix test-driven and 'agile'. -- BrianCooke

[stuff from RunawayReligion moved out to CritiqueOfXpxec]

Okay, is it not our duty to analyze the environment in which we are forced to work to determine if XP can be applied or not? How about some of this risk analysis stuff? And I'm not talking about CriticalChain or any of that blather. When I started this assignment in July of '00 I was told that we were going to be developing in an XP environment. Sure thing. All of the XP stuff except for pair programming, short iterations, customer involvement, testing, and a few other minor priciples of XP. Needless to say, of course XP is a huge failure in such an environment.

As a result of that I always take time to point out to the site boss that we don't actually do any of the XP stuff on this project. XP hasn't really failed us here because we haven't tried it. But then I point out that the book says XP is not to be applied to the development of a product which is any of the following:

 - a platform for other products
 - fulfils a critical mission
 - has a long V & V cycle

Yah. What are we developing here? A platform-based crtical drug dispensing medical product. Oy!

When I get to the next gig I will evaluate the risk involved in attempting to employ XP on the product under development. My analysis will have to include such things as resistance from corporate culture, physical availability of space, direct customer involvement, etc. This seems to me to be an AND function. If any of the environmental conditions mitigate against it XP is bound to come up short. XP is kinda fragile in that regard and needs to be treated just like an intolerant religion based on ignorance over truth. Oops, sorry -- not exactly the analogy I wanted, but the closest thing I could come up with. -- MartySchrader

CategoryXpCritique, CategoryPaper, XpCritique, IconixOpinionOfExtremeProgramming