Rating: 
Summary: XP Refactored: Zen meets Pragmatism
Review: Extreme Programming (XP) has garnered an almost cult following over the last few years. Different companies have flocked to try it out, lured in by the promises of faster development, lower cost of change, and higher quality. Advocates such as Kent Beck have identified what they think are the most troublesome aspects of software development, flipped them around, and done them to, well, extremes. But is any practice healthy when done to cultish extremes? Few people ask this question, perhaps because of the near inquisitorial responses. Fortunately, Stephens and Rosenberg provide a welcome break.
In "Extreme Programming Refactored", they present a convincing argument that XP is not just not well suited for new development, but actually harmful. For new development, they present an alternative which uses a "defanged" version of XP which combines all of the practical benefits of XP without all of the problems.
-Overview-
We start with an objective overview of XP including the claims by many of its supporters and a look at C3 (Chrysler Comprehensive Compensation), the first and most popularized demonstration of XP in action. We see why XP was formed, what problems it tries to solve, how the different principles and techniques are related, and how it has worked in practice.
Not to give any secrets away, Matt and Doug don't see C3 as a clear success. To prevent larger shocks, they then walk us through some of the problems at a high level and introduce us to one of the metaphors which is central to the rest of the book: <em>a circle of snakes</em>. In this description, all of the different pieces of XP are dependant on the other pieces, so that if one piece should slide (pair programming, for example), then the entire circle will come apart and start to bite you.
This metaphor is elaborated throughout the rest of the book, and its appropriateness becomes more and more clear. We see how any break in the discipline can quickly lead to complete project failure. More worrisome, we see many arguments and reports from people who have attempted XP for why it is extremely difficult to maintain discipline. Even Martin Fowler, a strong XP supporter, writes that he has intentionally left XP for development because he didn't think it was possible to use XP and deliver in a timely fashion.
In keeping with the "refactoring" in the title, Matt and Doug finish by listing the admirable goals of XP and showing how we can actually achieve them. They call this being agile without being fragile. That is, they take the agile goals but add "decrease risk", "encourage contingency", and "prevent fragility". And, as a pleasant change, they back up their recommendations with practical experience which resulted in a successful project.
-Reactions-
I enjoyed reading "Extreme Programming Refactored". Matt and Doug are generally engaging and use humour to liven up the book and strengthen their case. I am just starting up a project which is borrowing heavily from XP, so their practical and substantiated advice is welcome and timely. Much of what they say isn't a huge surprise to me, but they did raise a number of issues I hadn't considered before.
They both obviously know XP, and have been involved in the XP culture for some time now. This has let them draw from many sorces and give us a good, expert opinion. However, they frequently use the language and acronyms of XP without explaination or definition. I found that I would have to frequently check an impromptu glossary that I prepared, and at times I just gave up and let the point slide. If their audience was XP converts, their jokes at XP's expense might not go over well, and if their audience was developers who were evaluating XP but hadn't used it, then some points are lost.
I found also that they try to build several arguments against XP, but they add in elements throughout the book. They must have been aware of this, as their cross-references occasionally read: see "Chapter 3 and pretty much the rest of the book". I found this occasionally frustrating because I wanted to use the book to sway my manager, but because the arguments were so dispersed, I couldn't point to one section, I have to wave vaguely at the entire book.
Those gripes aside, I found "Extreme Programming Refactored" to be a pleasant, occasionally funny, mind-opening read. I would recommend it to anyone that is contemplating starting up an XP project, and I would force it onto anyone that is currently working on one. For those people that are curious about all of the XP hype, this might also be a good book to read. It serves as a good ground to some of the cosmic claims of XPs supporters.
Rating: 
Summary: XP or XPR
Review: Firstly let me say that prior to reading this book I had never really bought into the "Xtreme" part of XP. I have rather tended to agree with the "moderate" XP views right from the beginning; this after trying to relate my experiences developing software with the XP practices, values, activities and roles. Nevertheless this book has made me add clarity to my understanding of what is good about XP and why (in addition to what so wrong with XP)About the book, I think the authors have made a reasonably good effort at pointing out the glaring pitfalls of XP while suggesting constructive alternatives. While it also attempts to set the record straight on the "success" (read failure) of the C3 project which is considered as the project that gave birth (atleast formally) to the XP practices, often it is hard to ignore the spite that the authors seem to have for the Xtremos. To an extent the parodies, satire and jokes all add up to this. This could have been avoided or atleast kept to a minimum (not that the p,s,j are bad :) IMHO, it is important to read this book (and even books advocating XP) with an OPEN mind. Relate whats written in the books with your experience, apply your best judgement in deciding what practices are suited for your project as well as realise the tight coupling between certain XP practices. (TDD is always good, constant refactoring makes sense sometimes, rejecting up-front design works only for small projects, Refactoring makes sense only if you also employ unit-testing ... all IMHO) The book also has advice on how to incorporate the 'good' XP practices in an organization without complete overhaul (Start with using safety-net practices). It is surprising to see some of the leading proponents of XP actually dismiss this book as poorly written. I would have imagined that they would have had a much more mature response to the book. They say that the book dismisses XP (which it does not) without any constructive alternatives (which it does provide if you care to read thru to the end). Wonder why they couldnt give a more constructive or atleast a more pointed criticism of the book itself rather than dismissing it on the whole. Xtremos huh... To summarize, take out the sarcasm (which at times borders on spite) and you have a good book.
Rating: 
Summary: Extreme Aberration
Review: I am giving 5 starts because it is not possible to give 6. Or 10. Extreme Programming is a product of Extreme Aberration. Stephens and Rosenberg provide the proof.
Rating: 
Summary: Big hopes - little substance - time wasted
Review: I was in a process of evaluating agile methodologies for my client with the goal of recommending and eventually implementing one (or more). After reading few books about XP (as the most promoted agile methodology) and getting understanding of basic principles, I was happy to see a book that promised to be critical about it. I hopped that XPR book will point out some common pitfalls and let me learn on other people's mistakes.
At the first glance XPR looked like it would be a very fun reading. It wasn't! Novelty of the book organization and approach wears off quickly. Jokes, notes and songs, funny at first, become boring very soon. I started ignoring distractions in a desperate search of substance, facts and useful information. I didn't find much.
Hype is bad, anti-hype is worse. Attitude of negativism becomes contagious and if you apply the same thought process on the book itself, you start noticing authors quoting themselves (!?), promoting their own products (ICONIX), using anonymous testimonials, playing dumb, failing to make a point when using testimonials (e.g quoting a guy who telecommutes that XP doesn't make sense for him - especially pair programming! Funny, very funny - not!).
I definitively didn't get what I expected from this book - a formidable case against XP. I did have few grins and laughs in the beginning, but if I wanted fun only I would buy a comic book. Time wasted!
I refuse to believe that arguments presented in this book are all there is against XP (XP future would be safe and sound then).
Rating:
Summary: Disappointing and annoying
Review: I was very sorry to have spent my money on this book. The authors try to be cute and make liberal use of sarcasm and snide jabs. Unfortunately it gets repetitious and really gets in the way of their message. After wading through all their critisisms, negativity and simplistic sarcasm I finally got to the part that suggests alternatives. I was peaved to discover that they basically support the goals of the XP creators they have roundly disparaged ad nauseum, and offer only some minor tweaks which are mostly valid, but not worth my investment. XP as originally proposed was simplistic and flawed. It is definitely NOT the final solution to development woes. However it has acted as a wake-up call countering the "process bloat" that tends to overwhelm many development shops. It is interesting to see most traditional methodologies incorporating some of the best ideas that were popularized (and not invented) by the XP proponents. These authors had a few valid points that could have been injected into a mature and reasoned debate. That could have contributed in a positive way to advance our work methods.
Unfortunately they are so negative and are so imbued with their own wittiness that it was a chore to plow my way through to the end of the book. Don't waste your precious time on this book. Do try to find another anti-xp book before commiting to a large project using XP! Go ahead and try to implement XP on some small projects, and do encourage frank and open discussions about process in your teams. Don't make a religion out of any working methods. If you take ONE thing from XP, do more automated testing and do create more opportunities for communication, both inside the team and with the customer.
Rating:
Summary: Disappointing and annoying
Review: I was very sorry to have spent my money on this book. The authors try to be cute and make liberal use of sarcasm and snide jabs. Unfortunately it gets repetitious and really gets in the way of their message. After wading through all their critisisms, negativity and simplistic sarcasm I finally got to the part that suggests alternatives. I was peaved to discover that they basically support the goals of the XP creators they have roundly disparaged ad nauseum, and offer only some minor tweaks which are mostly valid, but not worth my investment. XP as originally proposed was simplistic and flawed. It is definitely NOT the final solution to development woes. However it has acted as a wake-up call countering the "process bloat" that tends to overwhelm many development shops. It is interesting to see most traditional methodologies incorporating some of the best ideas that were popularized (and not invented) by the XP proponents. These authors had a few valid points that could have been injected into a mature and reasoned debate. That could have contributed in a positive way to advance our work methods.
Unfortunately they are so negative and are so imbued with their own wittiness that it was a chore to plow my way through to the end of the book. Don't waste your precious time on this book. Do try to find another anti-xp book before commiting to a large project using XP! Go ahead and try to implement XP on some small projects, and do encourage frank and open discussions about process in your teams. Don't make a religion out of any working methods. If you take ONE thing from XP, do more automated testing and do create more opportunities for communication, both inside the team and with the customer.
Rating: 
Summary: Title should read "XP: kicked, stomped, and ridiculed"
Review: In buying "Extreme Programming Refactored: The Case Against XP", I expected a critical (case against XP), yet constructive (refactored), view on this popular Agile development methodology. What I found instead were copious amounts of sarcasm, irrelevant song lyrics, and enough icons and sidebars to make you lose track of the topic. To this you add a plethora of out-of-context quotes, web screen prints, and tales from disgruntled practitioners and you start hoping that you will soon get to the counter-proposal so that you can finally understand what the authors have to offer. After having read fourteen chapters (about time since the book only contains 16), you finally get to `Refactoring XP'...I am sorry to report that this chapter did not make up for the rest of the book. The counter-proposal was weak, unconvincing, and seemed to proposed more of a `RUP a la XP' than a constructive criticism of XP itself.
Rating:
Summary: Splendidly entertaining common sense
Review: Mixing humor with serious discussion is risky, but the authors have succeeded. Their criticisms of a fad methodology are fair and needed.
Rating:
Summary: Good book, and lots of fun
Review: Remarkably little has been published that is critical of extreme programming. "Questioning Extreme Programming" (McBreen) doesn't ask the really tough questions. Boehm and Turner's recent "Balancing Agility and Discipline" is a more even-handed exploration of agile practices--especially XP, but it's too polite and doesn't draw out the full implications of its arguments. XP Refactored is the first book to seriously and deeply critique extreme programming. The authors poke fun at the excesses of extreme programming, of which, by the definition of "extreme," there are many. The book contains the best critique of the legendary Chrysler C3 project I've seen, including a good discussion about why it really is more myth than legend. The authors do a good job of countering Beck's claim that "turning the dial up to 10" is a good idea. Although it isn't the most enjoyable part of the book, the most technically interesting part of the book is the chapter on "Extreme Programming Refactored." The authors see a lot of value in the specific practices of XP; they'd just like to turn the dial down from 10 on some of the practices, reorganize others, and tone down some of the religion. For the past couple years, some XP advocates have been advocating extreme programming with a fervor normally associated with deeply held religious beliefs -- attacking whenever their belief system is questioned. Historically, humor has been a good response to religious overzealousness, and this book is hilarious. It compares XP to a ring of poisonous snakes, a failed barbecue, and many other vivid analogies. Ultimately, this book is a polarizing book, much like XP itself. People who love XP will hate this book. People who hate XP will love this book. People who are open minded about XP will enjoy the book and get a better understanding of XP's minuses -- as well as its pluses -- at the same time.
Rating:
Summary: The title doesn't fit the book's content
Review: The biggest problem you will notice is that the authors tried to inject humor and satire. They failed and added plenty of hate and malice instead. As I read the book I found so much of it was just not well founded with facts.
Consider the source of so much of their information, the C2wiki. This is a discussion group! People who have no knowledge of Extreme Programming make outrageous statements and they are quoted in this book. Furthermore that discussion group's format is such that any comment can be changed by anyone. I noticed a mistake while reading this book so I went over to the source at C2.com and changed it! That is how fragile the so called facts are that this book is based on.
Much of this book is based on projects that neither Matt nor Doug actually participated in. It isn't hard to imagine that they get the facts wrong.
One would expect from the name of this book that Matt and Doug will tell us ways to change XP to meet problems that are faced on projects. There is only a very thin section of a couple pages that deals with this. Almost the entire book is devoted to showing that XP should not work.
Then Matt describes a project he runs using XP and guess what? It works! He uses the core of XP with a couple peripheral changes. He changes the twice per day integration to once per day. He scales back on pair programming. He uses use cases instead of user stories. He spends extra time creating design documents. The core of XP is still intact and it works.
How to refactor XP should have been the focus of this book. What ideas can you take from XP that will help your project now? What can you change from standard XP and still survive? Do you need a book that is 50% song lyrics, 45% misquotes, and only 5% useful information?
One thing that is continually reinforced by the example projects in this book is that XP is very different from traditional processes and you must understand the differences to do well with XP. You can not learn anything about XP from this book because it promotes and glorifies a misunderstanding of what makes XP work. There are now two ways to develop software and a good understanding of both and when to use one or the other is vital information. You won't get that from this book because the authors chose a format that isn't informative.
If you want some good satire you should read Mr. Bunny's Big Cup O' Java. If you want to learn something about Extreme Programming get a different book.
|
