Slashdot Mirror

maffstephens writes "With the release of NetBeans 4.0 set to reignite the open-source Java IDE war and all sorts of cool developments on the horizon, it seemed like a very good time to talk to one of the key senior NetBeans developers. In this interview, Tim Boudreau (co-author of NetBeans: The Definitive Guide) speaks candidly about his views on rival IDE Eclipse, the future of NetBeans, and the thinking behind its new Ant-based projects system."

maffstephens writes "With the release of NetBeans 4.0 set to reignite the open-source Java IDE war and all sorts of cool developments on the horizon, it seemed like a very good time to talk to one of the key senior NetBeans developers. In this interview, Tim Boudreau (co-author of NetBeans: The Definitive Guide) speaks candidly about his views on rival IDE Eclipse, the future of NetBeans, and the thinking behind its new Ant-based projects system."

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

maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."

maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."

maffstephens writes "Have you noticed how difficult it's become to develop software? Not because software is more complex, but because there seems to be an army of administrators standing in your way - sys admins, network admins, database admins, runtime admins - the list is endless. They should be there to help us, to make our lives easier, but the reality is often very different. This thought-provoking article from Software Reality is all about the emerging culture of spiteful, dog-in-the-manger prevention amongst corporate IT administrators. Software development has become so inefficient as a result, it's no wonder so many companies are outsourcing."

fancellu writes "Extreme programming (XP) first hit the mainstream programmer consciousness a few years ago, with the publication of Kent Beck's Extreme Programming Explained. XP was controversial back then (and still is), because it argued in favour of hitting the 'reset' button on accepted software development practices." fancellu reviews below Extreme Programming Refactored: The Case Against XP, and offers this disclaimer: "I should point out that I get a couple of small mentions in this book (the authors quote an email from me), and I also happen to agree with a lot of what the authors say. But I'll try to be as impartial as I can with this review." Extreme Programming Refactored: The Case Against XP author Matt Stephens and Doug Rosenberg pages 400 publisher Apress L.P. rating 9 reviewer Dino Fancellu ISBN 1590590961 summary Bold critique of extreme programming - at last someone is prepared to say "The emperor is buck naked."

The Previous Extreme - What XP Set out to Fix It had previously been accepted practice to spend months (years, even, on large-scale projects) gathering requirements, then another year or two on design, before a single line of production code had been written. The infamous "big bang delivery" occurred when this gigantic monolith of a software system was finally delivered to the customer, only for the customer to retort that this was nothing like what he wanted.

It was also accepted practice to divide the system into separate subsystems, and attempt to integrate them after several months. By this time, each subsystem would have taken on a life of its own, and integrating these disparate monoliths together gave a whole new meaning to "plug and pray."

How XP "Fixes" It XP takes the development process to the other extreme, by shortening the "waterfall" lifecycle to weeks, days, even minutes. In fact, Kent Beck describes XP as a "waterfall run through a blender." Iterations typically last for a week or two; there is a high emphasis on code quality via unit testing; and code is integrated "constantly" so that it never becomes out of synch with the rest of the project. Beck is often quoted for saying that the XP practices "turn the dial all the way up to 10" -- that is, if something is good (testing, integrating, pair programming etc), well then, let's do it all the time.

There's a lot to be gained from learning about XP, and agile practices in general. However, many feel that XP has taken things too far. By taking things to the opposite extreme, we're just introducing a fresh set of problems. The optimum solution, then, must lie somewhere between these two extremes. That is fundamentally what Extreme Programming Refactored (XPR) is about.

Optimizing the Process There's been a lot of controversy surrounding this book. It grew out of an equally controversial article that appeared on the author's website. XP advocates were arguing on Yahoo! Groups over XPR's good and bad points, miraculously, months before the book was even available. XP zealots were even posting messages telling others not to buy the book, before they'd even had a chance to read it for themselves and find out what it's all about.

It's important to note that XPR isn't the anti-XP slam piece that some people had been expecting. It does rip into the XP practices in plenty of detail, but importantly it also describes alternatives, and talks about the good aspects of XP.

The authors make the argument that "turning the dial up to 10" mostly isn't such a good thing, and that to achieve our "holy grail" development process, we just need to turn the dial down a little bit -- let the milk simmer rather than boil over. We can do this by adding in some additional practices that take the burden off the overloaded, heavily interdependent XP practices.

For example, not everyone likes to pair program (with two people sitting at one computer). It just isn't for everyone. However, XP relies on everybody in the team pairing all the time. So if you don't like to "pair up," what choice do you have but to leave the project? XPR adjusts the other practices, placing a bigger emphasis on up-front design and documentation, so that pairing up doesn't have to be mandatory.

XPR also argues that it is possible to achieve a decent design before writing the code. The authors don't want a return to "BDUF" (Big Design Up Front), but instead to achieve an ideal middle-ground. The result is more akin to the monthly Sprints found in Scrum (www.controlchaos.com).

Similarly, XPR argues that the customer (and users) usually do have a pretty good idea what they want from a new system, and that they don't have to see a live system first before realizing that they wanted something entirely different. The authors argue in favour of interaction design as a way of achieving this goal.

XPR achieves all of this with more than a mild dose of satire. It's important to realize this -- the book is essentially "taking the piss" out of the more extreme XP practices, and the quasi-religious Extremo culture that has quickly grown up around XP. It has lots of serious things to say, but has a slight danger of that being lost "in the chuckles." There again, the danger is less to do with the book, and more to do with the reader.

XP sealots will never be swayed by such a book, naturally, but they are not the audience. It is for those undecided, or the cowed XP skeptics who know something is very wrong at the heart of the beast, but haven't have the words to say it. Even for zealots, I'd hope they'd put the hatred for long enough to at least temper their XP actions, to turn the dial down a little, to read the contents with the possibility in their minds that XP isn't the final perfect expression of all programming methodologies. Just for a while...

If you are scared of the contents, a favorite XP accusation, then of course you'll point out the 'needless humour,' blah blah, anything rther than address what the book says. Form will be far more addressable than content. It's the old "ignore this man, he wears a colourful tie" excuse, pick on some small detail that you feel is a weakness and totally ignore all the embarrassing questions you'd rather not address. If you like the contents, then the humour will be seen as a playful, court-jester like addition to what is a seriously analytical book

In conclusion, this book is well written, thought provoking, and above all entertaining (an aspect which seems to be proving almost heretical among some XP advocates). I found this to be a fun read, unlike some books, it was never a chore. It's extremely conversational, like having a cynical, wise-cracking guide. It's a pity more computer books aren't this fun. A spoonful of sugar and all that...

In fact this book is pretty damn wonderful. I know, it may sound a bit gushing, but before you review my review, give the book a read yourself. It's a thing of beauty, a rare mix of positive and negative, sweet and sour, opinion, and XP's favorite emotion, courage, courage enough to say "the emperor has no clothes." I can't see how you could read this book from beginning to end and not see XP in a different light.

In fact, XP programmers would do well to read this book, as it presents the negative path, something other than sunny-day scenarios. Using these warnings and guidelines, they'd have much more successful projects, as this book points out the dangers of lack of XP discipline, fragility and so on.

The truth is that I couldn't do justice to this book in such a short review. There is just so much evidence, so many contradictions pointed out, endless damning words from XPer's own mouths. It was supposed to be a small book to start of with, 150 pages or so, but due to the sheer body of evidence and submitted real life stories from those in the trenches, it bloomed to 400+ pages.

As Doug Rosenberg says "I don't want to be nearby when somebody decides to deploy an air traffic control system or some missile-targeting software that has been developed with no written requirements, and where the programmers made the design up as they went along." At least don't say you weren't warned!

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.

fedor writes "Software fashions come and go, but they always claim a few victims on the way. Where there's fashion, you'll find that rather weak willed person who is the Stupid Fashion Victim (or the SFV for short). This great article from Software Reality is all about fashion in software. Do you all remember WAP? In a couple of years some of the current 'technologies' will be gone too. The article mentions VB.NET, struts and XP as current fashion..."

fedor writes "Software fashions come and go, but they always claim a few victims on the way. Where there's fashion, you'll find that rather weak willed person who is the Stupid Fashion Victim (or the SFV for short). This great article from Software Reality is all about fashion in software. Do you all remember WAP? In a couple of years some of the current 'technologies' will be gone too. The article mentions VB.NET, struts and XP as current fashion..."