Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Extreme Programming Refactored, Take 2

timothy posted more than 10 years ago | from the don't-keep-that-all-bottled-up dept.

Programming 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.

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.

Summary

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 bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Could someone refactor the review? (5, Funny)

Anonymous Coward | more than 10 years ago | (#8660715)

It's extremely long.

Yeah, like MY BIG BLACK DICK!!!!! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8660779)

BURN!!!!

your mom knows what I'm talking about

Could someone dress appropriately for Judge Judy? (-1)

Fecal Troll Matter (445929) | more than 10 years ago | (#8660804)

I come home from work to watch the courtroom almost everyday, and I cannot believe the rags these people wear to seek justice!

Like my BIG BLACK DICK!!!! (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8661267)

BURN!!!

Text of the article in case it gets /.ed (-1, Redundant)

Anonymous Coward | more than 10 years ago | (#8661303)

[Posting as AC so I can't be accused of karma whoring.]

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.

Summary
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.

Early post (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8660718)

fight the war and fuck the norm... [anti-slash.org] ... JIHAD!

CowboyNeal (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8660724)

Has a cute ass.

I have this book... (-1, Redundant)

Chuck Bucket (142633) | more than 10 years ago | (#8660728)

Trying to show the shortcomings of XP in a satirical way and proposing changes to make it less fragile is a noble goal, and this book has some points to make. Its vast majority is composed of misunderstandings and logical fallacies, though.

Many XP practices are violently misrepresented. The "thorough analysis" promised on the front cover often comes down to quoting an XP proponent out of context and making fun of it. One of the most ridiculous examples is when they quote Ron Jeffries with "'There must be food' is a core XP principle" and then hold XP responsible for the vermin problem of a company.

Another common pattern is the reference to a project which failed to implement XP followed by the conclusion that XPs demands are unrealistic. Reports of successful implementations are with a handwaving attributed to not doing XP by the book.

The style of the book is questionable, too. At times its tone is quite aggressive - ideas are called "idiotic", XP proponents are accused of intellectual dishonesty. Quotes of XPers are marked with a picture of Marx Groucho, so that you don't accidentally take them seriously. I don't think that satire is good in making someone understand a new concept; satire based on an already distorted view feels painfully pointless.

If you have already made up your mind about XP and enjoy making fun of it, you might like this book. I can't recommend it to anyone interested in a serious criticism, though.

CVb

Parent is plagiarised. Mod down. (5, Informative)

Anonymous Coward | more than 10 years ago | (#8660799)

The parent was copied from here [javaranch.com] . Mod it down for plagiarism.

Re:Parent is plagiarised. Mod down. (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8660828)

It should have been pretty obvious to mods that the article was posted two minutes before a post that obvious took more than two minutes to write.

Re:Parent is plagiarised. Mod down. (-1, Offtopic)

Chuck Bucket (142633) | more than 10 years ago | (#8660864)

It should have been pretty obvious to mods

yes, it *should* have been, but it was not. This is why we will not STOP FIGHTING AGAINST THIS INJUSTICE! [anti-slash.org]

Cbe

Re:Parent is plagiarised. Mod down. (0)

Anonymous Coward | more than 10 years ago | (#8661100)

>>It should have been pretty obvious to mods
>
>yes, it *should* have been, but it was not.

That's what meta-moderation is for. Luckily for me I meta-moderated today and guess which post came up! Say bye-bye to one of those bad up-mods. No instant karma for you...

Re:Parent is plagiarised. Mod down. (0)

Anonymous Coward | more than 10 years ago | (#8661229)

The front page says:

Have you Meta Moderated [slashdot.org] recently? Regular Meta Moderators are more likely to get mod points

That's why I routinely metamod all negative moderation as "unfair". I should be swimming in mod points for that!!!

Re:Parent is plagiarised. Mod down. (0)

Anonymous Coward | more than 10 years ago | (#8660995)

Actually subsribers are allowed to see the story before it is posted, giving them enough time to formulate a well thought out response even before the article is published.

So. Actually not obvious in that sense.

Re:Parent is plagiarised. Mod down. (-1, Offtopic)

Chuck Bucket (142633) | more than 10 years ago | (#8661010)

I have this book... (Score:4, Insightful)

haha!

Re:Parent is plagiarised. Mod down. (1)

Uber Banker (655221) | more than 10 years ago | (#8661084)

Not insightful but +5 informative.

Re:Parent is plagiarised. Mod down. (0, Offtopic)

Chuck Bucket (142633) | more than 10 years ago | (#8661128)

I found this book to be much more interesting than the parent poster. It reveals far more about XP's refactoring than I knew about. Also, yep, the end ranking never matters, it's how long it's in the four to five range that counts; that's when you get replies and such. it's silly, but fun to do at work.

so don't just go by one review.

CB

yet it keeps getting moderated up (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8660889)

interesting, that.

Re:I have this book... (1)

dracocat (554744) | more than 10 years ago | (#8660908)

It is always amazing to me how great the divide is between XP advocates and XP Cynics. The desparity between your post and the review is amazing, and in fact I get a similar separation of extreme opinions when reading any message board, articles, or even books for that matter.

What is it that is keeping programmers from reaching a consensus on this. Was Object Oriented design as controversial as XP is?

I'm Cynical... (4, Insightful)

Greyfox (87712) | more than 10 years ago | (#8661285)

XP is just another way of designing software. If you have good programmers and managers it will work well. If you don't, it won't.

I'm cynical of the people who see it as a silver bullet that will solve all their problems. These are the same people who saw C++, Java and XML as silver bullets that would solve all their problems. Yes, I'll just wave my magical fairy wand and this technology will somehow make softare design easy and yet allow you to retain your six digit salary. This will happen shortly after the monkeys fly out of my butt.

Re:I have this book... (1)

Surt (22457) | more than 10 years ago | (#8661331)

The problem is that XP works.

Well, in some situations anyway.

Not all situations, really.

Ok, only in some very specific environments, with specific types of programmers.

And XP has been proven by experience not to work in many many environments, and has a legion of programmers who have had bad experiences with it.

OO on the other hand was mostly only controversial because people cared about the performance hit. Most people thought it was a good idea, but not practical. Then the compilers caught up, and the hardware got fast enough, and the benefits of OO outweighed the penalties.

XP has flaws that are permanent and unfixable for many programming projects/environments.

I would like to see a study. (4, Interesting)

BoomerSooner (308737) | more than 10 years ago | (#8660963)

Take a problem, and two teams of similarly formed people, give them the same project, and see what happens. You make one team go XP and one go traditional.

I bet traditional would do better in this test because you'd need defined docuements to code. Now if you took those same two teams and gave them my boss (feature creep, no dev schedule, sells a feature before it's developed, etc), the XP team would live and the traditional programmers would be bald from pulling their hair out.

In development I've found you just go with the flow and try to keep your sanity.

Re:I would like to see a study. (1)

Frizzle Fry (149026) | more than 10 years ago | (#8661087)

I don't think this would be too helpful. The question in my mind is mainly how feasible XP is for large, long-term projects, since that's where lack of documentation, etc., will really bite you in the ass. Unless this study is going to employ two teams of programmers full time for a few years, it won't accurately be ableto show that.

Re:I would like to see a study. (1)

Uber Banker (655221) | more than 10 years ago | (#8661135)

Take a problem, and two teams of similarly formed people, give them the same project, and see what happens.

To be statistically significant you'd need to do this several times over with several pairs of programmers. Your programmers would have to be a representative sample of programmers in your hypothesis, and the problem (or better several problems) would have to be representative of real life problems.

Slashdot is proof that a reasonable opinion can be instantly improved upon!

Re:I would like to see a study. (1)

geekoid (135745) | more than 10 years ago | (#8661332)

so XP is better in the real world.

Re:I have this book... (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8661031)

what a douchebag! wish I had some mod points

I just started reading this book (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8660733)

Last Sunday, SUNday, SUNDAY!

definition: (2, Funny)

skinny.net (20754) | more than 10 years ago | (#8660746)

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.

Re:definition: (-1)

Brando_Calrisean (755640) | more than 10 years ago | (#8660807)

I had Mexican food for lunch.. I've got enough fecundity to last me a week thank you very much!

Oh, wait...

Can someone just explain this in plain talk? (0)

Anonymous Coward | more than 10 years ago | (#8660756)

exTreme Programming, refactoring, man when I read this, the only thing that comes to mind is reducing equations while downhill biking on a 60% grade hill.

Someone please distill these ultra hyped buzzwords into something that doesn't sound like something from an ad agency selling sports drinks.

Re:Can someone just explain this in plain talk? (1, Funny)

Anonymous Coward | more than 10 years ago | (#8660784)

This book is for you if you want to integrate leading-edge technologies, recontextualize viral e-commerce, expedite synergistic communities and seize front-end ROI.

You can't do that, because (0)

Anonymous Coward | more than 10 years ago | (#8661335)

It's a book about buzzwords. It's virtually impossible to discuss this without using them.

XP in a nutshell (0)

donbrock (705779) | more than 10 years ago | (#8660775)

Extreme Programming = more than one person working on the same program.

Re:XP in a nutshell (0)

Anonymous Coward | more than 10 years ago | (#8660813)

Extreme Programming = more than one person working on the same program.

Great for OSS developers because their time is free but computers aren't.

Re:XP in a nutshell (1)

ciroknight (601098) | more than 10 years ago | (#8660863)

Whoa... wait... does this mean that more than one programmer actually wrote Windows XP?

I'm SHOCKED!!!!

Re:XP in a nutshell (1)

curtoid (415759) | more than 10 years ago | (#8660952)

I remember doing this back in '94. We had one good computer (a mac) and attached two keyboards with mice to it and programmed side-by-side on it. Weird.

Re:XP in a nutshell (5, Funny)

Neil Blender (555885) | more than 10 years ago | (#8661005)

Did your code look like this:

int int mamainin (voidvoid) {{

pprintrintff(("%.3ff", "3"vavall;);

retreturn 0;urn 0;

}}

Re:XP in a nutshell (1)

tjmsquared (702422) | more than 10 years ago | (#8661030)

Collective ownership of code is part of XP, but hardly describes it "in a nutschell". I'd say that a better description of XP in a nutshell would be "Test driven iterative development".

Re:XP in a nutshell (1, Funny)

Anonymous Coward | more than 10 years ago | (#8661351)

Dude, nobody owns code. It wants to be free, man. Information wants to be free!! And I'm not out of order! You're out of order! The whole freaking system is out of order! You want the truth? You want the truth! You can't handle the truth! 'Cause when you reach over and put your hand into a pile of goo that used to be your best friend's face, you'll know what to do! Forget it, tjmsquared - it's Chinatown.

eXtreme book reviewing. (-1, Flamebait)

the_consumer (547060) | more than 10 years ago | (#8660788)

This is eXactly what /. needs, redundant book reviews from slightly different points of view! Kudos, Sarusa! If I see 3 more reviews of this book here by the end of the week, I'll subscribe!

buzzword phenomena (4, Insightful)

stonebeat.org (562495) | more than 10 years ago | (#8660795)

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.

Re:buzzword phenomena (2, Insightful)

_Sharp'r_ (649297) | more than 10 years ago | (#8660943)


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...

Re:buzzword phenomena (1)

bay43270 (267213) | more than 10 years ago | (#8661327)

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.

Re:buzzword phenomena (0)

Anonymous Coward | more than 10 years ago | (#8661384)

I think your missing the point. "car" in this context is a buzzword, in reality it just the most popular and marginally efficient means of transportation. Its alot easier to say Car. or Wagon. Or Boat. It all depends on the time frame.

XtremeProgramming is just a term for efficiently programming.. supposedly.. IANAP

Dang (5, Funny)

AviLazar (741826) | more than 10 years ago | (#8660811)

Who needs to buy the book, i read the whole thing in the article :)

-A

Re:Dang (5, Funny)

Anonymous Coward | more than 10 years ago | (#8660918)

Who needs to buy the book, i read the whole thing in the article :)

No, I think the article is a little longer.

eXtreme! (3, Funny)

thebra (707939) | more than 10 years ago | (#8660837)

The word "eXtreme" makes me feel like I'm doing some thing atheletic.

Re:eXtreme! (0, Offtopic)

strictnein (318940) | more than 10 years ago | (#8661127)

does that scare you?

The outside is nice... and warm.. high of 65 today!

Can I have a Cold Cathode, Wha?? (-1, Offtopic)

zerocool^ (112121) | more than 10 years ago | (#8660842)

Am I the only person who was surprised that the words "Bling" and "Bling" didn't appear in this article?

My experience with XP (5, Funny)

Anonymous Coward | more than 10 years ago | (#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.

Re:My experience with XP (5, Funny)

serano (544693) | more than 10 years ago | (#8661174)

Congratulations on your move to a profession known for its maturity and exemplary hygene.

Re:My experience with XP (1, Funny)

kin_korn_karn (466864) | more than 10 years ago | (#8661201)

hey, jennifer beales doesn't smell bad

Re:My experience with XP (4, Funny)

yerfatma (666741) | more than 10 years ago | (#8661234)

On the plus side, you could spearhead eXtreme welding. Unless those fit, sweaty men get distracting too. Or you have a disagreement about a weld that ends badly.

wait, what? (4, Interesting)

happyfrogcow (708359) | more than 10 years ago | (#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.

NO silver bullet! (4, Informative)

IO ERROR (128968) | more than 10 years ago | (#8660870)

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.

Re:NO silver bullet! (1)

truthsearch (249536) | more than 10 years ago | (#8661381)

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.

XP, Windows XP (3, Funny)

lightknight (213164) | more than 10 years ago | (#8660874)

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.

Customer responsibility (4, Interesting)

sphealey (2855) | more than 10 years ago | (#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?

sPh

Re:Customer responsibility (5, Insightful)

Angst Badger (8636) | more than 10 years ago | (#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.

Re:Customer responsibility (3, Insightful)

arkanes (521690) | more than 10 years ago | (#8661284)

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).

Re:Customer responsibility (1)

chromatic (9471) | more than 10 years ago | (#8661345)

Perhaps a better approach is to talk to the customer (whoever that is; usually a representative of who needs the software or who's paying for the software) regularly, balancing what the customer really wants with when and how the developers can produce it.

(Disclaimer: I wrote a book about that [oreilly.com] .)

Re:Customer responsibility (0)

Anonymous Coward | more than 10 years ago | (#8661287)

>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

Yes but... you aren't expected to be a civil engineer yourself. Whereas a full acceptance test suite supposes that the customer has a fair number of skilled programmers on hand. The problem isn't
expecting customers to provide a spec. it's expecting them to write large amounts of code. If they were happy to do that themselves why would they be customers?

Extreme Programming Debunk (0)

Anonymous Coward | more than 10 years ago | (#8660893)

Extreme Programming is 1 step Up or Down, depnding on your view, from adhoc programming.

most tired buzzword ever... (3, Funny)

handsome devil (611366) | more than 10 years ago | (#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."

Movie Spoiler: Extreme Programming Reloaded (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8660926)

Trinity dies at the end!

Stupid X acronyms.. (4, Funny)

CharAznable (702598) | more than 10 years ago | (#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

Re:Stupid X acronyms.. (2, Interesting)

dom1234 (695331) | more than 10 years ago | (#8661120)

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 like "YEEEAH man I do !!", but no one has ever defined what this means. This is as much ridiculous as it is a PURE buzzword... meaning simply nothing !

What is it about the X letter ? It's just a letter !

Re:Stupid X acronyms.. (2, Funny)

CharAznable (702598) | more than 10 years ago | (#8661161)

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.

my personal take.......... (2, Funny)

MisanthropicProgram (763655) | more than 10 years ago | (#8660953)

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!

Re:my personal take.......... (4, Insightful)

Kenja (541830) | more than 10 years ago | (#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.

Re:my personal take.......... (4, Insightful)

Frizzle Fry (149026) | more than 10 years ago | (#8661150)

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.

Re:my personal take.......... (1)

fastdecade (179638) | more than 10 years ago | (#8661198)

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 productive than apart, because they will still be able to pick up all the problems that only one of them would have spotted. Not to mention being able to talk to each other might actually teach them something, other than about which chicks they dig.

Phew. (-1, Offtopic)

MuMart (537836) | more than 10 years ago | (#8660980)

Does anybody else get the impression that this Sarusa person likes to talk - a lot? Wouldn't want to be stuck in a lift with them ...

What the fuck is a "lift"? (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8661186)

English, mutha fucka. Do you SPEAK IT?!?

Why not "EP" instead of "XP"? (4, Interesting)

MooseByte (751829) | more than 10 years ago | (#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!"

Re:Why not "EP" instead of "XP"? (1)

geekoid (135745) | more than 10 years ago | (#8661232)

Well, eXtreme Programming was out before XP, so maybe MS should change the name to Cross Point.

That said, I hate when they Capitaloze the wrong letter and then use it for an intial.
It is so stooopid.

Huh? (0)

No. 24601 (657888) | more than 10 years ago | (#8661022)

It was used to develop XP?

Nuff said!

What will the 2nd edition be titled? (3, Funny)

Chromodromic (668389) | more than 10 years ago | (#8661023)

"Extreme Programming Refactored Refactored"?

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

Rational Unified Process (1, Flamebait)

dustinbarbour (721795) | more than 10 years ago | (#8661047)

IMHO, the best overall programming methodology. Again, just an opinion.

Re:Rational Unified Process (2, Informative)

Mr. Piddle (567882) | more than 10 years ago | (#8661262)


Yes, finally we have a process, where the training program has been officially accredited and takes 2.5 years to complete. The resulting Ph.D. is very highly valued in industry, and many people exiting the program get hired on in the best bureaucracies around! The best part is that no programming is necessary at all!

Coming soon... (1)

slycer9 (264565) | more than 10 years ago | (#8661066)

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*

There's only one thing I can think of saying (0)

Anonymous Coward | more than 10 years ago | (#8661071)

Too many notes.

Fo' REALS! (-1, Offtopic)

Anonymous Coward | more than 10 years ago | (#8661079)

Surkeat tunarit [sonera.fi]

XP (5, Interesting)

Thanatopsis (29786) | more than 10 years ago | (#8661080)

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 (4, Funny)

GoofyBoy (44399) | more than 10 years ago | (#8661208)

>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.

General Principle (3, Insightful)

ReciprocityProject (668218) | more than 10 years ago | (#8661086)

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.

Was that the whole book? And.. (1)

Gr8Apes (679165) | more than 10 years ago | (#8661097)

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.

Frankly speaking (0)

Anonymous Coward | more than 10 years ago | (#8661115)

The people that can program well will continue to program well. The people that need 'methodologies' and other tricks to detract from the fact that they write half ass code will continue to rely on anything that elludes to giving the impression that they can write anything other then half ass code.

If someone can program, they can program. they don't need any 'methodology'. If they can't program, they need to get out of the business. We don't need you. Go get into real estate or something. It's not our fault you wasted all that time trying to become a programmer. Get a grip on reality and give it up. It's that simple.

It's not hard to tell who these people are. Usually, they are the religous zealots who will argue methods til they are blue in the face. the minute you don't immediateley understand some minute detail above their obviously flawed 'methodology' they deam you stupid.

They say things like "you don't even understand what such and such is. how do you know it's failed?" well, that's about the weakest argument ever and I despise people that use it. I might as well go argue with muslim extremeists.

Anyways, extreme programming sucks, and I don't need to read a 15+ chapter book to know that. The paired programming concept, while not a new approach, is beneficial in only some circumstances. An actual circumstance is when some dork head programmer decided to use some object oriented derivitive 'methodology' and wrote 5000 line of code that only two well focused software engineers with a huge whiteboard could figure out after the dork head programmer got shit-canned.

Reasons for XP (4, Insightful)

telbij (465356) | more than 10 years ago | (#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 (5, Insightful)

robslimo (587196) | more than 10 years ago | (#8661366)

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 (3, Insightful)

chromatic (9471) | more than 10 years ago | (#8661373)

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.

Why it's not taking off... (1)

geekoid (135745) | more than 10 years ago | (#8661194)

...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.

There is no silver bullet.. (3, Funny)

CharAznable (702598) | more than 10 years ago | (#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!"

It's nice to see... (1)

Cranx (456394) | more than 10 years ago | (#8661217)

It's nice to see XP taken to task like this. Nice slap back at all the sophomoric zealots I've had to argue with about it.

When will you IDIOTS get it through your head??? (-1, Troll)

Anonymous Coward | more than 10 years ago | (#8661253)

Sarusa is yet ANOTHER name for Jon Katz! Yes..... JON KATZ!

Katz is responsible for all these long winded, pointless book reviews. Being Cowboy Kneel's "special friend" gets him preferential treatment.

Sarusa = Honestpuck = JON KATZ!!!

FUCK OFF AND DIE, KATZ. EAT SHIT AND DIE, KATZ!!

XP Refactored (5, Insightful)

herwin (169154) | more than 10 years ago | (#8661273)

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.

Windows XP (1)

MonkeyCookie (657433) | more than 10 years ago | (#8661308)

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 (4, Insightful)

duplicate-nickname (87112) | more than 10 years ago | (#8661324)

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!

XP Refactored - for europe (1)

gr8_phk (621180) | more than 10 years ago | (#8661329)

Wouldn't "XP Refactored" be the comming release of Windows for europe?

Just like socialism? (1, Insightful)

Anonymous Coward | more than 10 years ago | (#8661383)

The mention of XP "pureness" reminds me of what socialists used to (or may still for all I know) say about the collapse(s) of communism - "they failed because they weren't practicing 'pure socialism'."
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?