XP Goes Mainstream | Extreme Programming Refactored: The Case Against XP

The amount of hype that surrounds XP means it was inevitable that it would be tried out, sooner or later, by a team (we d guess, many teams ) whose programmers couldn t be considered to be hard- core XPers ”that is, by people who don t study methodologies for a living (or even as an obsessive hobby) or by people who don t hang out on Internet discussion groups and endlessly discuss the same XP issues. ^[2] The success of XP in the hands of such non “ hard-core developers will be the true test of its viability in the mainstream programming world.

A well-defined methodology will get its point across clearly and be adopted by teams to great effect. The key to an effective software process (at least in the mainstream of software development) is that the people who try it shouldn t have to be process experts to understand it. Leave it to the methodology creators to be experts ”the rest of us just want to grab a process off the shelf and benefit from its clear and unambiguous wisdom. A process that is absolutely correct in what it teaches will, almost as a direct consequence, be clearly and unambiguously defined, resulting in fewer misunderstandings.

So, if we re to believe that XP is correct, clear, and unambiguous, why does it result in so many misunderstandings about what it really teaches?

Smell the Code, Jack

(Sing to the tune of Hit the Road, Jack by Ray Charles)

Smell the code, Jack
And don t do design no more no more no more no more
Smell the code, Jack
And don t do design no more . . .

Whoa baby, oh baby my code is so clean
It s the cleanest smellin code that you ve ever seen
I don t need design, figure what the heck
I can just sit back and drink some Becks

(That s right)
Smell the code, Jack
And don t do design no more no more no more no more
Smell the code, Jack
And don t do design no more . . .

XPers Don t Do Design (or Do They?)

An example of the mainstream confusion that surrounds XP is the erroneous message that XPers don t do design. XP is very clear that it s not about not doing design. It actually involves a lot of design work, just not (we would argue) at the right time or at the right level of abstraction.

The message that leaks out of its parallel Extremo culture and into the rest of the programming world, however, is often very different.

VoXP
Voice of eXPerience: Tales from the Front Line

A couple of months ago, Matt received an e-mail from someone who had read the article The Case Against Extreme Programming
( http://www.softwarereality.com/ExtremeProgramming.jsp). The e-mail (whose author asked to remain anonymous due to fears of losing his job if certain Extremo zealots found out he had written it) included these comments about XP in the real world :

Tales from the front line. Here s what happens in a real XP group :

”lead developers don t pair, yet insist that others do.
”we are packed into a tiny room shoulder to shoulder to foster pairing . In reality, it fosters a stinky noisy room and a headache .
”there are Java classes that are over 9000 lines long.
”business concepts/entities are represented as ArrayLists of ArrayLists of ArrayLists, i.e., Perl style aggregation. You see, in XP there is no design, thus no objects, only ArrayLists.
”every day we have a ˜stand up meeting where we tell the group what we did yesterday , what we will do today, etc. It has a very ˜cumbaya [sic] camp fire atmosphere.

Of course, much of what is described in this e-mail is contrary to what XP teaches. Once again, Doug s favorite quote, The difference between theory and practice is that in theory there is no difference between theory and practice, but in practice, there is proves to be true.

For example, properly refactored code would never result in Java classes that are over 9,000 lines long (shudder!) or Perl-style aggregation ( horror !). The lead developers should be pairing more than any of the others; they re supposedly the experienced ones, after all, so they should be imparting their knowledge and experience to the junior coders.

We discuss expert-novice pairing and other pair-programming combinations in Chapter 6.

The e-mail captures exactly the sort of thing that really goes on in projects where the teams think they re doing XP. They aren t hard-core XPers; they don t have time to read all 20 XP books and absorb their many subtleties. The result is that Partial XP must be increasingly common in the mainstream programming world. The core message that XP sends out isn t sufficiently clear and unambiguous to prevent teams from adopting Partial XP (just the parts they understand or think they understand) in an ad-hoc, unplanned manner.

XPers Don t Do Documentation (or Do They?)

Another example of mainstream confusion in XP is its apparent recommendation not to do any documentation. Of course, XP isn t saying not to do any documentation, just not to do unnecessary documentation. ^[3] So what s wrong with that? Well, it leaves plenty of room for confusion and misinterpretation by non “hard-core teams who are faithfully trying to adopt XP.

The trouble is that the Extremos interpretation of unnecessary is probably-quite different from that of XP newbies. XP regards design documentation as unnecessary because its other practices make up for it. This is probably a bit too subtle for people not well versed in XP thinking. Thus, the erroneous message that spills out of the Extremo culture and into the mainstream is simply don t do documentation. The more cynical among us (Doug, for instance) find parallels between the don t do unnecessary documentation marketing pitch and you can t smoke until you re 18 cigarette advertising. Squarely targeted at young, slightly rebellious, wanna-be-cool teenagers . . . we mean programmers.

XP in the Mainstream

Another, major risk is that as XP becomes more popular (or at least, as what people think XP is becomes more popular), XP will be applied to the type of project for which it just isn t intended. The hype and overselling of XP doesn t help to lessen the confusion. Put simply, XP might be acceptable if it s being used in exactly the intended circumstances (small project, single room, on-site customer) by a team whose members are well versed in the XP ways and who know exactly what they re doing. The advertised XP successes that we ve seen are mostly to do with very small-scale projects, so no surprise there. However, the horrific likelihood is that there s a dirty underbelly of unreported XP failures instigated by teams that have been swept up by the hype, but that don t really understand XP. ^[4]

This is what happens when something goes mainstream. Mainstream people-start using it. If something isn t ready for mainstream ”in XP s case, if it isn t sufficiently well defined to get its core message across clearly and unambiguously ”then it usually sinks without a trace. That is, unless it has a sufficiently well-oiled hype machine to keep it moving and has caught the mainstream imagination so well that its failures and deficiencies just don t seem to matter.

^[2] Issues such as Why can t we base an entire software process around the concept of an on-site customer? Because the concept is broken! But then C3 would have been a failure, and I saw it reported as a success! But C3 was a failure! Oh.

^[3] See http://www. xprogramming .com/xpmag/Misconceptions.htm .

^[4] As we have progressed through various stages of writing and editing this book, the horrific likelihood we originally wrote about has become much more of a certainty . Even as we re getting ready to go to press, we re continuing to receive Voice of eXPerience contributions, which you ll see throughout the remainder of this book. Please note that every single one of these Voice of eXPerience contributions is a real-world, actual, true story. As one of our correspondents puts it, The stupidity level exceeds our ability to make this stuff up.