Become a fan of Slashdot on Facebook


Forgot your password?
Programming Books Media Book Reviews IT Technology

Extreme Programming Refactored, Take 2 277

Sarusa writes "eXtreme Programming has been quite the lucrative phenomenon, with a slew of articles and a bookshelf full of 20+ books on the subject, rivaling even UML for fecundity. With all the hype, where's the opposing viewpoint? Well, it's not often as profitable to write a book on the downside of a hot trend, but Matt Stephens and Doug Rosenberg managed to find a publisher for Extreme Programming Refactored: The Case Against XP by Matt Stephens and Doug Rosenberg, henceforth referred to as XP Refactored because I'm eXtremely Lazy. This book is not intended entirely as a hit piece - as the title indicates, they do spend some time examining what works in XP and how it can be used sanely. (Please note that this book has been reviewed on Slashdot once before, but from a slightly different perspective.)" Read on for the rest of Sarusa's review.
Extreme Programming Refactored: The Case Against XP
author Matt Stephens and Doug Rosenberg
pages 432
publisher APress
rating 8 of 10
reviewer Sarusa
ISBN 1590590961
summary A book you should definitely read along with 'Extreme Programming Explained'. Makes its points quite well, though a bit over the top in places.

Where I'm Coming From

I've worked on several large projects (and innumerable small ones) as programmer and/or system designer. I thought long and hard about shelling out my $30 for this book (list price is $39.99, but you can find it for less online), and more importantly, scheduling the time to read it. I pride myself on being a software engineer, concerned with not just cranking out code, but overall system design. On the other hand, after being subjected to various overkill design methodologies, such as full-on UML, I'm wary of things that keep you so busy designing and reading books on the subject that you never get around to doing anything. One of the authors of this book (Rosenberg) is a big UML advocate and has written at least two books on the subject, so I was suspicious.

I want to like XP because I feel strongly about several of XP's source tenets -- such as frequent releases, not bloating the code right now with reusability that will never be needed, refactoring often, and unit testing. And of course it looks sort of 'open-sourcey.' Power to the programmers! I finally decided I had some time to spare, so I lined up Extreme Programming Explained by Kent Beck, Extreme Programming Installed by Ron Jeffries, and XP Refactored.

The Outline

XP Refactored starts out by examining eXtreme Programming's basic methodologies and its central claim: In other methodologies, making changes to the project takes exponentially more resources the further along you are in the project. If you make a big change after two years of development, it costs a lot more than a big change after one month of design. XP's basic claim (even if they don't enunciate it this way very often) is to flatten the cost of change by keeping everything in a state of flux all the time. In their words, Embracing Change.

There are 12 canonical XP Practices, and a couple more which weren't part of XP originally but are now gospel, such as collocating -- the entire team needs to fit in one room, or some of the Practices break down. The book goes through the four values, the four activities; basically you get XP in a Nutshell right up front. And the authors do a good job of presenting these in the spirit intended, I think -- after reading this chapter you might feel that XP is a fine thing.

Then we start getting into the juicy bit you bought the book for. They start by examining the infamous C3 project at Chrysler. This was the poster-child XP project that launched XP to stardom and spawned a flood of magazine articles and 20 books on the subject. It was started in 1996 as a payroll system to replace the payroll system running on Chrysler's mainframes, because Chrysler was pretty sure that the Y2K bug would cause all their mainframes to keel over on Jan 1, 2000. Kent Beck was brought in, and he brought in the others. The project was canceled in Feb 2000, when it was apparent that it was still nowhere near done and the mainframes were still working after the drop-dead date.

This chapter really sets the tone for the book. First, we get the too-clever-for-my-taste Beatles filks (song parodies). We get a fairly concise summary of what happened along with references for you to study if you wish. We get lots of satire from the authors. We get copious quotes from XP gurus hanging themselves with their own rope -- and this proves to be one of the most powerful techniques in the book. You are given all the URLs you could ask for to further research the subject yourself, including the XP gurus' own takes on what happened. You will learn that to XP people, 'inexplicable termination' of a horribly late project that has failed in its very reason for existence can be Success. It is at this point that, if you love XP, you will probably fling the book against the wall and walk away. As gleeful as the XP camp was in trumpeting the early successes of the C3 project, the authors of XP Refactored are just as gleeful in dissecting the final outcome and the subsequent confused disarray in the XP camp -- such as TerminationCanBeSuccess.

The next chapter, 'The Case Against XP,' provides the manifesto for the book. It lays out the authors' case in a step-by-step overview. You won't be convinced of anything after reading this chapter, but it summarizes and provides references to later chapters.

'Extremo Culture' examines what kind of people are attracted to XP, how XP plays on the natural inclinations of most programmers who will be attracted by some of the good ideas and not-so-good ideas XP builds on, and the XP culture of fear. XP is obsessed with Fear and Courage -- you must have Courage to do XP, and if you oppose it, it's because you're Afraid of it. You need to be corrected or eliminated (off the team, nothing more violent than that). The only thing that causes project failure is Fear - either you were afraid of XP and weren't doing it right, or someone outside was Afraid of your XP project. I found this chapter quite fascinating, because I could see a lot of myself and the people I've worked with in it.

Having laid out the Practices, and The Case Against XP, the book takes on each of the practices in turn and gives it a thorough going over. This is the largest section of the book, as there are 12 (plus) Practices to cover in detail. The outcome of the analysis is generally negative, though not always -- the authors feel that XP's emphasis on unit tests is a good thing in general and should be expanded to other methodologies. They like frequent releases, just not quite so frequent. The Pair Programming chapter is perhaps the most gleeful, because it's arguably the worst idea in eXtreme Programming when taken to the eXtreme of no programming alone, ever, so there's plenty of fodder for wit and demolishment. But they also examine how Pair Programming is part of the Practices because it's required to compensate for other XP fragilities. This chapter is available as a sample chapter on the authors' website.

After examining the Practices, the book looks at the outcome of another XP research project: what would you expect to happen based on the previous chapters in the book, what did the study report show happened, and what can we learn from this? The predictions of the XP Refactored authors seem to be mostly borne out, and of course they say this proves XP is a bad idea. Though in the end, the study authors said, "But we liked XP anyhow." So you can draw your own conclusions on this one.

And finally, in perhaps the most practical chapter, they take XP and Refactor or 'defang' it. XP makes use of some good ideas, after all. The major failing is taking them all to extremes on the theory that if chocolate tastes good you should eat nothing but chocolate (You think that's silly? Beck reasons exactly this way.) This chapter suggests how to combine XP with real software engineering practices to hopefully achieve manageable, predictable results. Combine flexibility with actual design and risk control. Perhaps not surprisingly, this method resembles a lot what you'll often find small teams of skilled programmers doing on their own. And if you asked them what methodology they were using, they might even say eXtreme Programming, even though they aren't.

What Doesn't Work?

Let's start with the bad. The song parodies are unrelenting and painful. If you like filking for the very idea of delicious subversion of media to your own ends, or you are the kind of person who loves any web comic that mentions Star Wars simply because it mentions Star Wars, you may think these are clever. At least they're easy to skip, but severely hamper the utility of handing this book to a manager and saying, "Please read this, it's important." The prose satire sequences and Monty Python skits are less painful, but again often too self-satisfied for their own good. But sometimes nothing makes your point like satire.

If you're a big XP fan coming in, you will almost certainly be turned off by the relentless skewering of XP. Then again, I don't think this book is aimed at you, nor is this review.

XP Refactored does an excellent job of providing all the ammunition you will need to convince anyone who might be thinking of foisting pure XP on you that it's a bad idea, even in manager terms. However, it doesn't provide an 'executive summary' chapter and it could definitely use one - simply because no manager is going to read through this entire book, much of which is in programmer-speak. Chapters 2, 3, 14 and 15 all almost fit the bill, but it needs one chapter with references you can just rip out and hand to your boss to read between holes of golf.

What Works?

Advocates of a position usually fear the other side, and will try to prevent you in some way or another from being subjected to the opposition's best arguments. On the contrary, the authors of XP Refactored seem to feel that the more you read about XP, in the words of Extremos themselves, the better their anti-XP case is made for them. Quotes are used relentlessly, and by the end of the book you will have the eXtreme suspicion that most of the XP authors are making everything up as they go along with no worries about consistency. Which, if you think about it, is pretty XP -- all the contradictory injunctions can be refactored later. Very often the authors' best case against XP is made by a prime quote from an advocate, with reference supplied so you can go verify that it's not out of context, of course.

Secondly, there are frequent Voice of Experience sidebars, which consist of feedback from people who have been involved in XP projects. The authors say they did not solicit these, but when word got out that they were doing the book they started getting submissions anyhow. They delayed the book and added 25 pages in order to fit the VoXP sections. That was very smart, because these notes from the field are quite visceral and provide powerful contrasts between XP in theory and XP in practice -- simply reading the authors' arguments would not be nearly as convincing. For example, the field stories of how XP coaches or managers tend not to do Pair Programming, even while they make everyone else do it, because they hate it too.

XP Refactored is not relentlessly anti-XP, though it sure may seem like it at first blush. The authors do a good job of presenting XP ideas in terms that are not unflattering before they dissect them. They do acknowledge that many XP practices are just good ideas that have been 'turned up to 11' on the theory that more is always better, and will point out the core of a good idea. For instance, rapid releases are a response to the problem of massive unwieldy design methods where everything is supposed to magically all come together at first delivery way down the road, and often doesn't. They also point out that most of XP is a pretty good mode in which to maintain already developed and mature software.

This book makes an important distinction between two levels of XP - the 'official' XP, which is what you'll get in the books (though that's often contradictory) and the 'Extremos' position, which is what you get when the authors argue amongst themselves on Usenet or Wiki and are less guarded and more honest. This is an important distinction as far as theory vs. practice. You'll glean from the various quotes and URLs, if you haven't read the XP books, that Kent Beck is a fairly intelligent guy and knows when it's smart not to go into too much detail on a delicate subject, and when it's time to move on to other causes like Test Directed Development. And then you've got people like Ron Jeffries and Robert Martin who should be thanking their personal gods every day that XP came along and gave people as horribly unqualified to manage or design software a bandwagon to hook onto.

I was a bit harsh earlier on the song parodies and satire sections, but in many cases humor is used quite well to expose the underlying weaknesses or contradictions in XP. That old British humour serves its purpose, and should be well received by the geek audience for the most part. Do you like User Friendly? You should love this.

Finally, the book does an excellent job of clarifying the cultlike nature of XP. How it appeals strongly to coders who think they're being oppressed by The Man and claims to empower them while reducing them to a commodity. Anyone who opposes the culture it is Afraid of you, and needs to be eliminated (non-violently) or ignored. If your XP project fails, it is because you weren't Really Doing XP - any deviation from XP is what lead to disaster. However they'll also tell you it's so flexible you can feel free to change it in any way to fit your way of working. Except you must always Pair Program. Except when you don't. Got that? You may think I am stupidly oversimplifying here, but no, quotes and references are provided. And I'd already gotten a lot of this just by reading two pro-XP books (XP Explained and XP Installed).

Key Points

If you are already pretty sure you want to read XP Refactored, you may want to just skip this section. These are key points I got from reading the book, and of course they're made in far more detail and more cogently in the book itself. This is where you'll find it's pretty clear that I ended up siding with XP Refactored, as well.

The most important argument XP Refactored makes, and uses as a basis through the rest of the book, is that XP is a highly fragile web of high-risk practices which are woven in a tight web to minimize the damage from the other bad practices. These are (mostly) worst-practices that coders engage in because, heck, the most fun part of programming is the coding. So XP attempts to compensate for them and turn them into virtues. For instance, the lack of written documentation is balanced by the code sharing and pair programming, which are supposed to make sure that everyone knows everything about the system. If any one of the practices is not followed religiously, the whole thing comes crashing down. This is referred to as the 'circle of snakes' and is an excellent distillation of what XP books continually hint at but don't tell you outright. XP Refactored goes through each Practice and shows how failing to stick to it causes everything else to collapse, domino-like.

The circle of snakes means that XP (and this is my own analogy, don't blame the authors) is a precariously controlled free-fall, which should get you to where you want to be faster than hiking if you can maintain control. But people don't stick to the practices 100%, because they're very high discipline, the circle unwinds, and the snakes are venomous. As usual in the book, this viewpoint is validated by plenty of quotes from the Extremos themselves, who will tell you that any XP project failed only because you deviated from XP. And XP is such a high discipline methodology that unless you are continuously coerced back onto the true path, you will deviate from it; this is also covered in the C3 chapter, where it happened to even the Poster Child XP team.

XP's indifference to design is pretty astounding to anyone who's gone through any reasonable sized project. The theory is that you don't add anything more than you need at the moment. YAGNI (You Ain't Gonna Need It). And to a certain extent this is a good idea - if you're writing a small memory pool system, there's no need to turn it into a full blown memory manager 'just in case'.

But to use an XP example from the book, if you're working on an program that will need to work with objects on several different systems (local disk, database, web, ftp) but right now you're only got the disk based story card (user stories being broken up into small tasks) you hard code everything in your program to go right to the disk. Even though you know that you will need web support, because the customer insists on it, you are not allowed to plan for that whatsoever by adding a layer of abstraction between your code and the abstracted 'object holder'. Rather, when someone needs to add web support, they will just code it right in, maybe at least out in a separate web class. It will have a slightly different interface than the disk class, since there's almost no design, no planning, and different people coding it. Then later on you will refactor the code and merge these three or four different systems, make them behave the same, and clean up the code.

This is incredibly expensive and error prone for something that could have been avoided with even a little thought up front. You can say that any decent programmer would of course realize this was what was needed to be done, and add the abstraction layer. But you are no longer practicing XP. You made it needlessly complex for the moment, and added a requirement that might be removed.

There is no need for any large scale design in XP because it will naturally 'emerge' from continuous refactoring. As Kent Beck says, "The larger the scale, the more you must rely on emergence." You can treat a 10,000,000 transaction per second system as if it were a 1 transaction per second system. You write the 1 tps system, then the 10,000,000 tps system will just be 'refactored' from the 1 tps system when necessary. You don't need to worry about degenerative interactions between different parts of the system. You don't even need to worry about any error handling or out of bounds cases because that's not simplest possible design, until the customer codes up acceptance tests that trigger these. If you've been on a real project you're probably gasping for air now.

These next few points are points you can bring up with your management if they decide to do XP since they read a neat article about it somewhere. I know arguments that appeal to management aren't necessarily going to be seen as a good thing by coders, but if you've had some project experience they should make you break out in a cold sweat too.

An incredible burden is shifted to the 'customer' in eXtreme Programming. The customer (representative), in the room at all times, is responsible for expressing all the requirements in the form of short use stories (which can be jotted down on a card) and in the form of code, as acceptance tests. The customer is now responsible for everything, and if anything doesn't work, it's the customer's fault for not making their tests stringent enough. Given the extremely low likelihood that anyone is going to dedicate a senior designer/programmer to work with the XP team indefinitely, this tends to fall on someone more 'expendable'. Who is still expected to do a massive amount of work and know how to code and take all the responsibility for the project while having no real authority over the XP team that's implementing it. It should come as no surprise that this is a high stress, high burnout position and that the XP people are trying to 'refactor' this requirement constantly. Now ask your manager who the 'customer' is going to be.

Excellent management ammunition also comes in XP's total inability to deliver your requirements on time - it's quite up front about this. This seems a little strange for something that claims to make your development more rapid, but one set of XP gurus will tell you that XP can deliver by a fixed date, but not a known set of deliverables, and another will tell you that XP can deliver any fixed set of deliverables, but not by a known date. Which works out to be equivalent. Other methodologies often deliver late, but XP doesn't even try, and this is because XP totally punts any real design or scheduling. You can't tell how much emergence or refactoring it's going to take. Let's hear it in their own words:

"One of the most important principles in planning for Extreme Programming is that the dates are hard dates, but scope will vary.'" -- Kent Beck and Martin Fowler.

"There is a difference between 'Schedule' and 'The Schedule'. In XP, 'Schedule' is very important, but 'The Schedule' doesn't exist per se. ... The reality, of course, is that a software project is never done until it has been terminated." -- Robert C Martin

"Once you accept that scope is variable then suddenly the project is no longer about getting 'done'. Rather it's about developing at a certain velocity. And once you establish a velocity then the schedule becomes the customer's problem." -- Robert C Martin

My favorite quote in the whole book also comes from Robert C. Martin:

"If you lose a card, and if the customer does not detect that loss, then the card wasn't very important. If, however, at an interaction planning meeting, the customer says: 'Hay [sic], where's that card about blah, blah, blah,' you'll find it easy to recreate."
Did you get that? It's okay to drop customer requirements in the trash, and unless the customer remembers to code up an acceptance test checking that requirement... the joke's on him! The customer can request you do some documentation, any documentation, monsignor please, only by writing up a story card - how often do you think those get lost? And lest you think this is just a moment of weakness, XP Refactored supplies other quotes from XP gurus encouraging you to dink with the user story cards as it suits you.


XP Refactored largely succeeds in the task to which it set itself: countering the hype of XP, or at least defanging it and making it sane. It won't make any difference to the fanatic adherents and their book empire, but this is an excellent guidebook if anyone tries to foist XP on you, or if you'd been making sideways glances at XP, curiously attracted as it batted its eyes at you. You can tell they had fun writing it, so it's mostly a fun read.

It could sorely use an executive summary chapter consisting of only the most compelling points with references, and please, no humor. For giving an executive to read when you're threatened with XP since he read about it somewhere.

Now I know people are going to read this and indignantly retort that XP is based on some good ideas, and I fully agree. XP's starting assumption, as explicitly stated by Kent Beck, is that if a little of something is good then as much of it as possible is even better. I like chocolate, but I'm not going to eat to exclusion. I further know people are going to respond 'But XP doesn't require you to _x_!', where _x_ is something like lack of design, or not planning ahead. This again is part of the cultlike beauty - you can claim any conflicting interpretation of the Rules you want. The primary advocates often do - Robert Martin says You Must Pair Program, Ron Jeffries says it's an ideal only, except where he says it's absolutely required, but if you fail then it's because you deviated from pure XP. Is that a little breathless? Well, no wonder.

XP Refactored really clarified my uneasiness with XP after reading the two XP books - first it simultaneously devalues real software engineering by providing justifications for ditching it all and treating programmers as commodity items. Secondly the horribly risky practices, combined with the incredible hype, seems to be setting us up for a return to crushingly restrictive, mind numbing waterfall methodologies when it shatters in the field like the fragile flower it is. As already happened at Chrysler, where even Smalltalk and the concept of Object Oriented were tarnished by association with the C3 project.

If you find yourself drawn to XP, as I was, I suggest you read Extreme Programming Explained, by Kent Beck, then this book. Hopefully you can read these and come away with a good idea of what works in XP and what doesn't. Perhaps you might feel the urge to unit test a bit more. Or do rapid release with at least some sane amount of design. Frankly, I got a better feel for the actual strengths of XP from Refactored than I did from any of the pro-XP books, including Explained. Which is pretty good for a book whose stated purpose is to deflate XP.

You can purchase Extreme Programming Refactored: The Case Against XP from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

Extreme Programming Refactored, Take 2

Comments Filter:
  • by Anonymous Coward on Wednesday March 24, 2004 @05:20PM (#8660715)
    It's extremely long.
  • definition: (Score:2, Funny)

    by ( 20754 )
    I was going to read this whole thing, but there was too much fecundity.

    fecundity-The quality or power of producing abundantly; fruitfulness or fertility.
  • buzzword phenomena (Score:5, Insightful)

    by ( 562495 ) on Wednesday March 24, 2004 @05:26PM (#8660795) Homepage
    I think extreme programming has been always there in form or another (just like evil). It is just the buzzord (i.e. XtremePrograming) that is creating all the hype.

    • Yeah, lazy (which isn't always a bad thing, some kinds of laziness are good for efficiency) programmers who fly by the seat of their pants trying not to get too close to the sun (ok, a couple cliches and puns there...) have always existed, but now they get to call themselves XtremeProgramming specialists on their resume.

      The resume they'll need badly once they manage to almost fully implement XP...
    • That's like saying cars existed 200 years ago simply because all the basic technologies in a car existed. Just because you worked side by side with someone on a program doesn't mean you were doing XP.
  • Dang (Score:5, Funny)

    by AviLazar ( 741826 ) on Wednesday March 24, 2004 @05:27PM (#8660811) Journal
    Who needs to buy the book, i read the whole thing in the article :)

  • eXtreme! (Score:3, Funny)

    by thebra ( 707939 ) on Wednesday March 24, 2004 @05:29PM (#8660837) Homepage Journal
    The word "eXtreme" makes me feel like I'm doing some thing atheletic.
  • by Anonymous Coward on Wednesday March 24, 2004 @05:31PM (#8660857)
    I was involved in several programming projects which used XP. The problem is that the IT industry is filled with overweight dorks with hygiene problems and who lack social skills. So every time I was paired with another programmer, I was subjected to his body odors, immature comments (constant Microsoft bashing, etc.), and the constant crunch of Doritos. It drove me up the fucking wall. I am now a welder and I couldn't be happier. Mod this down if you want, but this is the honest-to-God truth.
  • wait, what? (Score:5, Interesting)

    by happyfrogcow ( 708359 ) on Wednesday March 24, 2004 @05:31PM (#8660862)
    Kent Beck was brought in, and he brought in the others. The project was canceled in Feb 2000, when it was apparent that it was still nowhere near done and the mainframes were still working after the drop-dead date.

    So you're telling me that the basis of extreme programming is a failed and cancelled project? live and learn i guess.

    • Re:wait, what? (Score:3, Insightful)

      Well, not exactly a "failure". It appears to have been a project that was never necessary in the first place. Once management saw that nothing happened on January 1, 2000, they started wondering exactly what they had been spending all their money on - especially when they still didn't have a working system that would have solved the alleged "problem". It's a wonder that it took them as long as a month to cut their losses and stop the ongoing waste.

    • by BlackHawk-666 ( 560896 ) <> on Thursday March 25, 2004 @05:54AM (#8665547) Homepage
      Wow, it looks like all my previous projects are successes after all! Thank you XP for teaching me that success is whatever you want it to be and need not be measured by the hard taskmaster of goal completion.
  • NO silver bullet! (Score:5, Informative)

    by IO ERROR ( 128968 ) <> on Wednesday March 24, 2004 @05:32PM (#8660870) Homepage Journal
    Sorry folks, but there is NO one right methodology that you can just take out of the box and apply to any project, small or large. And the relative importance of such things as design, unit testing, documentation etc., do vary. Of course coders don't like anything other than coding, but that doesn't make the other stuff any less necessary. The project requirements might, though.
    • I would just like to add there's not always only one right methodology for a project, either. Sometimes 2 or 3 methods might work equally well.
    • Of course coders don't like anything other than coding, but that doesn't make the other stuff any less necessary.

      What are you talking about? I love writing documentation. It's like an outline or rough draft. I write out how I want my code to work and what it's supposed to do, which usually really helps me clarify in my own mind what I need to work on. Analytical writing skills also translate quite well to code analysis, so if you think about your project from that perspective you'll usually find s

  • by lightknight ( 213164 ) on Wednesday March 24, 2004 @05:32PM (#8660874) Homepage
    The two have a lot in common. They both look nice from a distance, but once you start using them, inexplicable thoughts of violence race through your mind...

    Having said that, Windows has come a long way from the 9x series.
  • by sphealey ( 2855 ) on Wednesday March 24, 2004 @05:33PM (#8660886)
    An incredible burden is shifted to the 'customer' in eXtreme Programming. The customer (representative), in the room at all times, is responsible for expressing all the requirements in the form of short use stories (which can be jotted down on a card) and in the form of code, as acceptance tests. The customer is now responsible for everything, and if anything doesn't work, it's the customer's fault for not making their tests stringent enough.
    Well, that's pretty much how all other professional disciplines work (except architecture, which tends to have the same problems as software development for some strange reason). If you give a set of specs for a bridge to a civil enginering design/build firm, and those specs don't call for the bridge deck to actually meet in the middle, you have no one to blame except yourself when the completed bridge doesn't bridge anything (unless you were smart enough to write a "professional responsibility" clause into the contract).

    But for some reason, business units think they can toss some poorly written requirements at a software team, "dedicate" a junior supervisor or even a junior secretary (seen it happen) at less than 25% of full time as the project representative, and expect to get a usable product back. Of course, when they don't it is the "techies" fault for having "poor communication skills".

    So while I am not a big fan of the total XP package, this one is actually right on the money. If the customer can't do the acceptance test, who can?


    • by Angst Badger ( 8636 ) on Wednesday March 24, 2004 @06:11PM (#8661242)
      So while I am not a big fan of the total XP package, this one is actually right on the money. If the customer can't do the acceptance test, who can?

      To a large extent, as a developer, I can, and do. Sure, the customer's approval is itself the final acceptance test, but the customer is not going to appreciate missing and mis-features because they weren't explicitly spelled out. AFAIC, it's the developer's responsibility to figure out what the customer actually wants, by active questioning and other methods, because only the developer knows enough about software development to fully appreciate the engineering issues, and pragmatically, a doofus customer is going to be a doofus customer whether you play passive-aggressive head games with him or not.

      All of this buck-passing misses the point in two ways. First of all, it's everyone's responsibility to serve the needs of the organization to the best of their ability -- be it a company, a university, a government agency, or an open source project. Sure, there will be people who won't, both in management and in development, but the impact of slackers isn't ameliorated by retaliating with more slacking. And secondly, from a purely self-interested cover-your-ass point of view, when a project fails, the hammer will fall on you before it falls on your idiot manager, if ever.

      Anyone who thinks this is going to change is probably also wondering why they no longer get recess and nap time. Dealing with incompetent and clueless coworkers, poor organization, and unreasonable expectations is just part of life. You can either deal with it constructively as best you can -- which might or might not mean seeking another job -- or you can turn it into an adversarial and ultimately self-destructive situation.
    • by arkanes ( 521690 ) <arkanes AT gmail DOT com> on Wednesday March 24, 2004 @06:15PM (#8661284) Homepage
      This is a perfect example of what the reviewer was talking about, which is taking a good idea and turning it upo to 11. You're totally correct that it's unreasonable for the customer to not support the developlment, and they have to take responsibility. Everyone who's ever worked in that sort of development knows the kind of mental anguish that last second or conflicting requirements causes. However, totally pushing that reponsability to the customer isn't correct behaviour either. There's ground in the middle that needs to be met. That, by the way, is how other professional industries work - the people you're contracting with are supposed to bring expertise to the table that you don't have (thats why you hired them, after all).
    • "You keep using this word "customer". I don't think it means, what you think it means".

      The golden rule applies. You know: "The one with the gold makes the rules".

      It's not fair, but if you tell your customer or manager that he has the responsibility because you're using eXtreme Programming, you won't be using it very much longer (assuming you still have a job).
    • by jc42 ( 318812 ) on Wednesday March 24, 2004 @08:19PM (#8662524) Homepage Journal
      If the customer can't do the acceptance test, who can?

      I've found myself on the developer side of this on numerous projects. The other side was either the QA people or actual customers. What I've done that works pretty well is: I code up tests for everything I can think of. I stick them in a directory called "test", and run everything there (in alphabetical order ;-) as a regression test after a change seems to be working.

      When the QA or customer rep makes the usual complaints about how complex and poorly defined their job is, I introduce them to my test suite. They are usually overjoyed that I've done their job for them. Then I tell them that I don't think I've done their job. My test suite is almost certainly incomplete. I give them a list of the things that I have tests for, and tell them to go off and think about it. I expect them to make suggestions for new tests.

      Their suggestions are sometimes good. Other times they are vague and unprogrammable. So I try to get them to clarify. And so on. It's somewhat random, but usually a lot of useful ideas come out of it.

      Eventually they have not just a "product", but a set of validation tests that show what it can do. And the contents of the test directory constitute a HOWTO for their own programmers stuck with the task of using the stuff.

      The one major problem with this is that it's difficult to program tests for features that require user interaction. Simulating a human is not easy. If that human is hidden behind a WIMP interface, it's nearly impossible, no matter what people will tell you when they don't have to do it themselves.
  • by handsome devil ( 611366 ) on Wednesday March 24, 2004 @05:35PM (#8660900)

    i have actually read up on the subject and do agree with some of the tenets of XP. however, i just can't bring myself to use the term "extreme" in regards to programming.

    To me, it conjures up visions of fluorescent spandex, hang-gliding, and the superfluous use of the prefix "bungy."
  • by CharAznable ( 702598 ) on Wednesday March 24, 2004 @05:40PM (#8660946)
    Is there anything more pointy-haired? eXtreme Programming.. eXtensible Markup Language.. Every time I see an X in an acronym my Buzzword warning goes off, unless it is something like Xylophonic Postamble or Xenophobic Mutant Litigation
    • by dom1234 ( 695331 )
      In Quebec, and probably in many other places in the world, it's quite popular to sell products that are X-treme (note the flashy absence of the first e, and the emphasis on the letter X). We see ads of X-treme shoes, X-treme sport accessories, etc.

      A radio station in Quebec city, named "Radio X", popular mostly to people aged 16-25, even invented a new concept named "the X attitude". They always ask people "have you got the X attitude ?" and the worst is everyone answers the french equilalent of something l
      • I suppose that when Generation Y starts to age a bit and get more purchasing power, we will have ExtrYm ProgrammYng Yntegrated Development Environment Windows YP (and Office YP) Mac OS Y and it will be very cool to write compilers using Yacc.
  • When I was eXtreme programming, the two of us just sat there and talked about chicks! One of us coded and the other talked about about the chicks we wanted to fuck. That's it in a nutshell. Sorry! We never looked over the other's [sic] shoulder when we were programming.

    yeah, yeah, check my spelling!

    • by Kenja ( 541830 ) on Wednesday March 24, 2004 @05:43PM (#8660970)
      "When I was eXtreme programming, the two of us just sat there and talked about chicks! One of us coded and the other talked about about the chicks we wanted to fuck. That's it in a nutshell. Sorry! We never looked over the other's [sic] shoulder when we were programming."

      So in other words, you where not extreme programming. You where just wasting time and CALLING it extreme programming. This is like saying that driving a car to work dosn't work becuase you just sat in your driveway drinking beer.

      • by Frizzle Fry ( 149026 ) on Wednesday March 24, 2004 @06:00PM (#8661150) Homepage
        But I think the point is that this always happens. No one who tries to follow XP is able to fully follow its tenets, and then their failure is blamed on not following XP, just like you're doing.
      • That's like saying you aren't using traditional programming because you didn't get all the requirements written down correctly before coding began.

        The question of how easy or difficult it is to get people to follow the rules of a methodology is a legimate measure of that methodology's effectiveness.

        Pair programming itself is based on the idea that an individual programmer can be a bit lazy and thus not double-check their work. Well, when you pair to lazy people together there's no guarentee that they will
    • the two of us just sat there and talked about chicks!

      Bzzzzt. "the two of us"???? Yes you program in pairs, but under XP, you're also supposed to exercise collective ownership. That means rotating frequently, so everyone pairs with everyone else. Ideas in the code spread that way.

      Now, if there were only two of you on the project, and both of you couldn't be bothered programming, then no methodology's going to fix that.

      It *has* been said that two cowboys sitting next to each other will still be more produ
  • by MooseByte ( 751829 ) on Wednesday March 24, 2004 @05:47PM (#8661014)

    Why can't the Extreme Programming crowd just call it Extreme Programming (or even 'EP') and not 'XP'?

    Otherwise even ignoring the obvious confusion with WinXP, it makes it seem like the concept is being marketed by some lame-ass over-hyped sports drink company.

    "It's programming... Xtreeeeeeeeeem!"

    Here's one for them:

    "Extreme Programming - It's slightly better... TO THE MAX!"
  • by Chromodromic ( 668389 ) on Wednesday March 24, 2004 @05:48PM (#8661023)
    "Extreme Programming Refactored Refactored"?

    3rd Edition: "Extreme Programming Refactored Refactored Extremely Refactored"?
    • Extreme Programming Refactored Refactored

      I think the third one will be:

      • Extreme Programming Revolutions
      As in when the programmers revolt and stage a cyber-coup.

      Seriously, I did some test-led development, and that really helped out in defining issues early on... not sure if pair-programming or use-stories would work (we extensively use UML use cases at the requirements stage).

  • on MTV.

    eXtreme Programming, followed by...the Osbournes.

    Seriously tho'...what had me scratching my head about this the most was the fact that they actually used the word 'fecundity' in a /. article.

    *walks away shaking head*
  • XP (Score:5, Interesting)

    by Thanatopsis ( 29786 ) <> on Wednesday March 24, 2004 @05:53PM (#8661080) Homepage
    Our former CTO was in love with XP. Why? Because it freed him from responsibility from things like designing with scalability in mind. XP works best in an institional setting where individuals are duplicating (or refactoring) an existing application or single purpose applications (say in a Fortune 1000 company). I would never use it for a new software product.

    We retained a couple aspects of XP (namely unit tests) but chucked many aspects of the methodology. Velocity was one of those concepts used by our CTO to explain why he didn't have to work more than 4 hours per day. Our board of directors got pretty tired of that after a while.

    He no longer works here.
    • Re:XP (Score:5, Funny)

      by GoofyBoy ( 44399 ) on Wednesday March 24, 2004 @06:06PM (#8661208) Journal
      >Velocity was one of those concepts used by our CTO to explain why he didn't have to work more than 4 hours per day.
      >He no longer works here.

      No, he just got so good at it he doesn't have to work more than 0 hours per day.

      Proof by example.
    • Re:XP (Score:3, Insightful)

      by dubl-u ( 51156 ) *
      Our former CTO was in love with XP. [...]Velocity was one of those concepts used by our CTO to explain why he didn't have to work more than 4 hours per day.

      People who like to spew bullshit will use whatever the hot topic is. That's not the fault of the hot topic.

      Because it freed him from responsibility from things like designing with scalability in mind.

      The way to do this in XP is to write "1000 people use the system simulateously" on a story card and then let the product manager decide when to pay fo
  • General Principle (Score:3, Insightful)

    by ReciprocityProject ( 668218 ) on Wednesday March 24, 2004 @05:54PM (#8661086) Homepage Journal
    In any field, you have a set of "best practices" that describe how best to go about solving problems in that field. Intelligent people don't argue so much about these best practices, or at least don't fight over them zealously, because each principle is either obviously flawed, obviously correct to the best of our knowledge, or obviously has some measure of merit. An intelligent, honest, and experienced person can consistently separate each practice into one of those categories.

    The fact that XP needs to make up a new word, "eXtreme Programming", complete with a capitalization error as though written by some half-d00d half-suit hybrid, and the fact that XP has to package a bunch of practices into one should tell you, before you have examined the practices, that the people behind it aren't interested in an intelligent, full and honest understanding of the best practices for computer programming.

    My humble proposal is that we ignore these people.
  • Wow was that ever long-winded.

    IMO, Some of the facets of Extreme Programming are great, but only as applied to organized process oriented programming. I strongly support working towards acceptance tests, however, I also strongly support up front design, so you know what you're supposed to code to. (The acceptance tests test the results, the design is the target). As for two people working together, only if one is a mentor, otherwise it's usually a major waste of resources.

  • Reasons for XP (Score:5, Insightful)

    by telbij ( 465356 ) on Wednesday March 24, 2004 @05:58PM (#8661132)
    The more I program, the more perfectionistic I get. When I was younger I would just start coding willy nilly because I didn't know what to avoid. I would just write and debug until something worked for me in the obvious cases. Nowadays I find myself thinking and thinking about every possible tangential issue I have ever encountered in an effort to avoid any possible future mistakes. Sure I write way better code, but it also takes me a lot longer.

    I think XP is partially inspired by a desire to recapture that youthful productivity (ignorant though it may be). Sometimes overthinking a problem can become paralyzing, and it actually is more efficient just to code it the first way that comes to mind then fix it later. So even though I have no real interest in XP per se, I definitely see the justification for a lot of the concepts.
    • Re:Reasons for XP (Score:5, Insightful)

      by robslimo ( 587196 ) on Wednesday March 24, 2004 @06:25PM (#8661366) Homepage Journal
      I've seen the same progression in my 18 or so years of coding experience, but to this

      Sure I write way better code, but it also takes me a lot longer.

      my experience disagrees. In my earlier career, I'd often blast out something that showed good signs of progress but had to have major redesign/recoding before the product could fulfill the requirements. I think my overall productivity is now much improved through forethought and consideration of design (though obviously some of the improvements come from the brute force of experience).

      I think XP is partially inspired by a desire to recapture that youthful productivity

      You may have something there. My disipline is the result of years at the 'school of hard knocks' and when you're busy getting 'hard knocks' you're not being used as efficiently right now as you could be. Some students never graduate from that school, so I think all coders can benefit from a structured methodology, the lesser experienced most of all. I just feel uncomfortable with what I see as an overzealous streak in this burdensome system (XP).
    • Re:Reasons for XP (Score:3, Insightful)

      by chromatic ( 9471 )

      I think it's rather that overdesigning and overgeneralizing (or in XP terms, writing code you don't need) is a waste of developer time and customer money better spent solving the customer's most important problem. Increasing programmer joy of programming is a nice side benefit.

    • and then, a few years later, you'll realize that over engineering is often just as bad as under engineering and you'll find the happy medium.

    • Re:Reasons for XP (Score:3, Insightful)

      by jc42 ( 318812 )
      This reminds me of a comment that I read some years ago about programmer productivity. Whoever it was (I've forgotten) remarked that older programmers usually take just as long to build something as novice programmers. The difference was that the experienced programmers produced much better software, that handled more than the obvious cases and didn't crash when handed bizarre input.

      Part of this was the observation that if you could walk through a company's software development areas, you could quickly g
    • Re:Reasons for XP (Score:3, Interesting)

      by mr_luc ( 413048 )
      Ironically, I find what you're saying is true.

      I'm only 20 years old, but I'm a very fast learner, and I am very conscientious about the quality of my code. Moreover, since I work on a very small team, I end up contributing to every single step in the process, from db/schema design to semi-advanced SQL coding (nested sets for hierarchies instead of recursion-based methods, for example) to object model planning and data/business/presentation separation planning -- and, of course, every phase of the actual pr
  • ...It puts the burdon of decision on the customer( usually managment).

    Show of hands: How man people have worked with a manger that would take responibility for decisions about every step of the program? hhmmm I see 1..oh wait he was just stretching.

  • by CharAznable ( 702598 ) on Wednesday March 24, 2004 @06:07PM (#8661209)
    As Fred "Morpheus" Brooks said, "Don't try to find the silver bullet that will deliver bug free code on schedule and on budget.. instead try to realize the truth, there is no silver spoon!"
  • XP Refactored (Score:5, Insightful)

    by herwin ( 169154 ) <> on Wednesday March 24, 2004 @06:14PM (#8661273) Homepage Journal
    I read that book first, and nodded my head. Then I started checking out some of the practices, and discovered that XP is actually pretty good. For example, pair programming seems to be able to produce the same results in about 55% of the time that one programmer would take, -->but with about 40% less software faults--. Not only does it get past the "9 women to produce a full-term baby in one month" problem, but with significant quality improvement. Just don't go overboard.
    • Then I started checking out some of the practices, and discovered that XP is actually pretty good. For example, pair programming seems to be able to produce the same results in about 55% of the time that one programmer would take, -->but with about 40% less software faults--.

      Ummm... yeah... but only because the terms "schedule", "late", "success", "bug" and "software faults" have been redefined so substantially. When the results are held to the same standards (i.e. on the originally-desired schedule,

    • pair programming seems to be able to produce the same results in about 55% of the time that one programmer would take, but with about 40% less software faults

      When I see someone slinging around unattributed percentages like that, the credability drops to 7.5% and my attention span drops to 0%.

  • Am I the only one who kept thinking of Windows XP when they were talking about "XP"? Windows "Extreme Programming".

    I thought that was a decent review: definitely more informative that most of the book reviews they have here on Slashdot.
  • Excellent Review (Score:5, Insightful)

    by duplicate-nickname ( 87112 ) on Wednesday March 24, 2004 @06:20PM (#8661324) Homepage
    I may not be a programmer nor care much about eXtreme programming, but this was still one of the best written book reviews I've seen on Slashdot.

    Other people submitting book reviews should read this one first. Thanks Sarusa!
  • Funny.. (Score:2, Interesting)

    by Kwil ( 53679 )
    ..Alistair Crowley wrote the same thing about Magic(k)

    So long as you perform it exactly right, it will always work perfectly. If it doesn't work, you didn't do it right, that's all.

    Sorry, I don't have time for things that either work perfectly or not at all. If I get something 99% right, I want something that works 99% of the time, thanks.

  • by CommieLib ( 468883 ) on Wednesday March 24, 2004 @06:34PM (#8661452) Homepage
    I looked at the XP stuff, semi-digested it and rejected it as marketing hype. But one portion of the process I've really embraced is the automated testing. Called Test-Driven Development, the idea is that rather than writing a test to test the code you've just written (like you have to do regardless) and then throwing it away, you keep it, and also place it in an organized framework where it can be run again and again.

    The upshot of it is that you're much les vulnerable to regression, or more precisely, that you can more readily see the effects. TDD is actually much more complicated than I've outlined here, but just search on JUnit (for Java developers) or NUnit (for Microsoft developers). Most of the big leaps forward are just formalizations of things good programmers already do, and I think that this qualifies.
    • Bah, this is called regression testing, and it was described in one book called "The Art of Software Testing" by Glenford J. Myers, which was published in 1978. *1978*! And that's probably not the first place it's shown up. The point is: Regression Testing ain't a new idea, so don't go crediting XP with it.

      Frankly, I think you misunderstand TDD. My understanding is that TDD also dictates that you write your test cases *before* you write your code. In this way, the tests are supposed to act as a formal
  • NEW eXtreme Programming Refactored, Take 2 Now with a side dose of Ritalin for those times when even you cannot control your code slinging madness. Take 2 and try again in four to six hours.
  • by Julian Morrison ( 5575 ) on Wednesday March 24, 2004 @06:39PM (#8661518)
    There is a specific type of "customer requirement" which is daft, trivial, probably useless to them from any "business use-case" perspective, and damaging to the overall project. These are often the result of whimsy inserted into requirements docs drawn up by the nontechnical, and followed with unreasoning precision when drawing together the spec.

    Silently dropping these in the trash is often the best way to test if the customer really wants them.
    • I find that approach really childish and not at all professional. It may take a little time but I'd rather point out the reasons it's silly a few different ways and compare it to other featurews of the system, to make the user reconsider a silly requirement.

      I look at it this way - if a requirement is really silly, then it should be easy to talk just about any user out of it. At the end you come out with a much healthier relationship between you and the client.
  • I'm trying to learn about XP by reading the O'Reily XP Pocket guide [], and "Agile & Iterative Development" [] by Craig Larman. My first takes are certainly not as critical as the "Refactored" book, but some of the points made seem reasonable to me.

    My problems with XP are:

    • The XP references to test development skip over a huge can of worms. Where I work (a disk drive company), the product firmware engineers don't write, or even know, the test system languages, and we use more than a few. In addition , ma
  • by Nygard ( 3896 ) on Wednesday March 24, 2004 @07:03PM (#8661742) Homepage
    So many of the nuances of XP have gotten lost here, it's very disheartening. Any methodology applied blindly will fail. Period.

    Early work on XP emphasized the human element of introspection. The review sets up a strawman argument about the rigidity of XP that may be supported by the newcomers like "Uncle Bob", but was not there in the original form.

    Originally, XP placed a lot of weight on continually asking yourself "Am I delivering value to my customer?" Followed by elimination of activities where the answer was "no". In other words, do more of the things that deliver value and less of the things that do not.

    Another nuance that has been lost is the idea that there are projects and teams that should not use XP. Kent's first book had a whole chapter on when not to use it.

    I've used XP in partial form, and it worked. I've used XP in full form, and it worked. The common denominator is that I had a team of creative, engaged, disciplined professionals working together. Such a team does not need a huge process to force them to do the right thing. It needs a set of common disciplines to unite them. This is what XP provides.
    • Huh. If you have "a team of creative, engaged, disciplined professionals working together" you will get good results no matter what methodology is alleged to be in use.

      Get good people who can work together and let them work, and you'll get good results.
      • While a small team of good people almost always produce good output, I think XP will give much better results than a heavyweight methodology like RUP.

        Conversely, a team of average or mediocre people using RUP will probably produce acceptable result, but if the same team uses XP (or another light-weight metodology) the project may very well crash and burn.
  • It's been replaced by the new methodology: "Offshore Programming" :

    (a) None of this "customer user story" crap that has management need to have regular contact with the development staff. Instead you give them the specs and they do the work without talking back to you. Management's time is valuable and can't be wasted on petty programming implementation details.
    (b) Wasting time on testing is foolish. You pay people to do the work, so they should do it right the first time. If not there are plenty of others
  • Has anyone used pair programming per se on a project? What was it like? Did you get any benefits? Were there times when it got in your way?

    I haven't, but I'm working on an open source hobby project with one other author. We tend to thrash out the high- and low-level design issues by email, sometimes at great length, and then one of us does the actual coding. This seems to work extremely well for us: we both understand all of the project well, and so can do maintenance as needed; we rein in the other'

  • "If you lose a card, and if the customer does not detect that loss, then the card wasn't very important. If, however, at an interaction planning meeting, the customer says: 'Hay [sic], where's that card about blah, blah, blah,' you'll find it easy to recreate."

    I remember going through XP programming or Planning XP and finding a beauty... (paraphrased)

    • ... if you need some testing infrastructure, database, web interface etc and have trouble justifing it to the client
    • just re-word a story so it has to be c
  • For your consideration the following passages:

    Paraphrased XP from the book/review:
    "XP is obsessed with Fear and Courage -- you must have Courage to do XP, and if you oppose it, it's because you're Afraid of it. "

    CMMI tutorial:
    "Adopter Types:
    Early Adopters
    Early Majority
    Late Majority

    The Innovators will be the first to embrace CMMI and the Laggards will be the last.

    The The Emperor's New Clothes:
    "Their colours and patterns, they said, were not only exceptionally beautiful, but the clothes
  • XP at my new job (Score:3, Informative)

    by roman_mir ( 125474 ) on Wednesday March 24, 2004 @11:05PM (#8663644) Homepage Journal
    My new company has adopted XP ways before I came on board. For the past 3 weeks I have been working in pairs with other programmers, I do not have my own station, we constantly exchange pairs. There is no high level architecture, there are design sessions. There is Swiki to keep whatever documentation we produce as we work on tasks. There is XPlanner to keep track of our time spent on tasks. XPlanner is also used as an integration token (when you want to integrate, you grab a token in it and only then you are allowed to check stuff into CVS.) Before you check into CVS all your code must have JUnit tests written (for every method) and the code must not only compile but also pass all the JUnit tests.

    Do I like XP? No, I don't. I think there is a major problem with not having a strong architectural design upfront (especially in our app., which is a back-end J2SE only data parsing - loading - networking system, with strict SLA time lines.) Pair programming? - I don't really care, if the company is paying for it, it is not my business. Of-course I hate the fact that I don't have my own station. JUnit testing everything, every method? I think that it is a great idea if you have the time. I find that it helps flushing out the bugs early on. Of-course it is the most time consuming portion of the coding exercise, especially if you have to mock all the database stuff before running your DAO tests. SWiki is a good idea, I think, but it is not a substitute for a high level design document. It is descriptive of the tasks but it lucks the perspective.

    Design sessions with all coders at once? A horible idea, but how are you going to share info when there is no documentation? Basically in XP you either do all of these things or your project will really go to hell. I don't like it. If all developers were to leave at once, another group could not find enough documentation on the business requirements of the project to continue working. XP blows in my mind, but it is a job for now.

  • by Animats ( 122034 ) on Thursday March 25, 2004 @02:28AM (#8664936) Homepage
    Bob Boyer and Jay Moore, of theorem prover and string search fame, used pair programming back in the 1970s and 1980s. They even had it working remotely. They were both using remote mainframe terminals into a DEC mainframe, and they had their screens slaved together. They also had headsets, so they could talk.

    Attempts to do this with PCs have been less successful, because synchronizing the displays tends to require huge bandwidth.

I never cheated an honest man, only rascals. They wanted something for nothing. I gave them nothing for something. -- Joseph "Yellow Kid" Weil