Extreme Programming Refactored

Written by DougRosenberg* and MattStephens.

[*The page of this name is a description not a homepage, unfortunately].

Has anyone else read this book yet? Care to comment? See http://www.softwarereality.com/ExtremeProgrammingRefactored.jsp for a summary.

I'd be interested to see what other people thought of it. It wasn't nearly the one-sided rant I expected - actually quite thoughtful. In fact in the conclusion seemed quite up-beat about XP.

Maybe ExtremeProgramming itself needs a bit of refactoring from time to time.

So this page has been created for the XP gurus who might want to reconsider previous ideas and positions, they might want to record here what if anything needs to be refactored. It should be a very interesting exercise, and probably a measure of the maturity of XP itself.

XP is "refactored" constantly. Every team has to adapt the practices to local circumstances. Some invent new ones. Many are reporting what worked for them and what didn't, thereby shaping XP. It's such a dynamic process that it probably would be hard to present anything really meaningful on a single wiki page...

[CategoryBook]

From: Susan Capparelle (suca@manning.com)

 Subject: XP Refactored Book Proposal for review 
 Newsgroups: comp.software.extreme-programming
 Date: 2002-03-20 12:56:52 PST

Hi,

We are a high quality computer book publisher seeking reviewers for a book proposal we currently have in hand entitled, "Extreme Programming Refactored: How to be Agile without being Fragile." The proposal is approximately 3,360 words in length.

Please contact us if this is something you might be interested in or if you can recommend someone who might be qualified and willing.

Thanks in advance.

Sincerely,

 Susan Capparelle
 Assistant Publisher
 Manning Publications Co.
 suca@manning.com
 www.manning.com

Posted to news:comp.software.extreme-programming on 3/20/2002: http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&group=comp.software.extreme-programming&selm=cbe436a1.0203201256.1abe4bae%40posting.google.com and http://groups.yahoo.com/group/extremeprogramming/message/45773

Took a look at the book for several minutes at Borders earlier today. Thus, I wouldn't consider the following a review so much as a first-impression.

As mentioned above, the book isn't exactly a one-sided rant. However, it does a good job of complaining about XP. The primary point it drives home is that, as described in several books (as well as on the Wiki), XP appears to be formless development without design. The idea that you can just RefactorMercilessly to eliminate virtually all design considerations, for instance, is considered and discarded (in other words, RefactorMercilessly as a substitute for design is a GrossExaggeration). Additionally, it drives home the absurdity of other XP concepts when they practiced in excess - for instance, a common problem in traditional software development deals with programmers who constantly perfect existing code at the expense of getting real work done. It also dismisses the 'flat cost curve' as a tautological argument - since XP dispenses with the phases of the ExponentialCostCurve, there will naturally be a flat cost curve! It argues that the manner in which so many costs 'just disappear' under XP is a matter of semantics, not time-saving. Etc. etc.

Some of its arguments seem weak - PairProgramming is, at first, dismissed as simply being so ludicrous nobody in their right mind should consider it. It treats the loose design philosophy via a straw man - since XP proponents claim that there is no design, just refactoring, how can you possibly just 'refactor' nothing into something? (As I understand XP - but mind you, I'm new to this - there are design phases. They just affect small areas of the system, or simple overviews of the entire system's structure (aspects, as it were) and those designs are subject to change at any time as new ideas or requirements emerge. Sound about right?)

It then, however, goes on to address the fact that evidence supporting the efficacy of PairProgramming is rather sparse. Although this isn't a good argument (heck, TheEconomist has reported on its efficacy - see entry at the beginning of PairProgramming), they provide several anecdotal examples of where PairProgramming has failed, though these appeared to all be WeTriedXpAndItFailed instances - that is, a bunch of SoloProgramming cowboys who didn't believe in XP were forced to pair up and things fell apart. Another (somewhat) valid argument is that, at least of the time of its writing, the only major XP project was the ChryslerComprehensiveCompensation project, which got canned. (I notice that VcapsProject also was successful, but has been mothballed as well - didn't see any references to it in the book.) On one hand, the WhoIsUsingXpForCommercialDevelopment page does show a very short list, but compare it with CompaniesDoingXp, which shows quite a bit of popularity. All-in-all, XP needs more success stories!

On the plus side, however, the book seems friendly towards a toned-down version of XP - essentially AlmostExtremeProgramming - where constant refactoring is combined with good up-front design (for instance, it's a lot easier to refactor your entire object model design early on than it is to constantly refactor limited sections of the model). Refactoring is encouraged, so long as it doesn't detract from completing functionality on time. And so forth. The biggest benefit of XP, they state, is that everyone who comes in contact with it becomes TestInfected - although the idea of UnitTests, AcceptanceTests, etc. isn't exactly a new concept, RelentlessTesting is a very wonderful thing to encourage in programming, and XP definitely promulgates this idea.

Generally speaking, the book argues that some isolated parts of XP are GoodThings, but that many more isolated parts of XP are BadThings. Their reasoning is that the BadThings don't work in "larger projects" - that XP wants to discard all planning save for the PlanningGame and to substitute design for programmers that RefactorMercilessly, and that this just won't cut it for a project of 'sufficient size'. For instance, the authors argue that UML is a very valuable tool for large-scale application architecture, and that to completely throw it out the window is absurd. Good point. However, last I checked (I admit, I'm a XP newbie!), I didn't think UML was heretical in XP. (And that's the very point of XP, isn't it? UmlLanguage? can be helpful, and you're free to use it to design, refactor, etc. - just remember that you can't safely design the entire system up front in UML, and no UML document is set in stone!) Heck, I started browsing through MartinFowler's UmlDistilled book after putting this one down!

As mentioned on the WeTriedXpAndItFailed page, this book, like many others, tends to isolate each specific characteristic of XP and finds its weaknesses.

One issue that bothered me quite a bit about the book (and seemed to detract from its authority) was the fact that a large amount of the book contained filler - classic songs turned into parodies about XP, satirical analogies of XP philosophy, etc. It's definitely a tongue-in-cheek analysis of XP. The inside cover contains a short quiz encouraging you to match up each absurd quote (sometimes, but not always out-of-context) with its source (one of the original XP gang, e.g. KentBeck, RonJeffries, ChetHendrickson and so forth). All-in-all, it seems like they had a handful of good arguments (and a lot more not-so-good ones), but needed to make the book as large as the others (xref. WhosWritingAboutXp) on the same shelf.

Hey, in the end, IfYouNameItTheyWillBlameIt.

-- Joseph Riesen

Reversed Impersonated Edit - not made by DonaldNoyes, if you want to make changes, RealNamesOnlyOrAnonymous

CategoryExtremeProgramming