Questioning Extreme Programming

by Pete McBreen

Book Overview

This text provides an attempt to understand and explain the controversy surrounding Extreme programming, and why readers must come to their own conclusion. This description may be from another edition of this product.

• Format: Paperback
• Language: English
• ISBN: 0201844575
• ISBN13: 9780201844573
• Release Date: January 2002
• Publisher: Addison-Wesley Professional
• Length: 201 Pages
• Weight: 1.06 lbs.
• Dimensions: 0.6" x 7.4" x 9.2"

Customer Reviews

Valuable read for the XP/Agile devotee

I'll tell you at the outset I'm a big fan of agile programming. I lived through many years of waterfall development and all the pain that ensued. Having been convinced of the power and flexibility of Agile methodologies though hands on expereince there is *no* going back (never say never, eh?). Although this book is written to debunk XP (no matter what the intro says), it doesn't do that job. What is does do very well is raise many of the questions that anyone intersted in Agile should ask themselves -- no matter if they have been practicing agile methodologies for years, or if they are just thinking about it. Even if your are a 100% died in the wool fan of agile/XP/whatever - this is a very valuable book. It'll cause you to think and question. And that is always good.

Good except the conclusion

If one ever read any other book about XP, one will find something missing about them: if XP is such a good idea, and if other software processes are really that bad, why those processes are created in the first place? Is there anything good about more traditional methods? And is there any other alternatives to XP and traditional methods? This book nicely fit this large gap. It goes on to explain why and how XP is designed, and its underlying philosophy. But unlike most other books, it also explain those for more traditional processes, and compare their pros and cons. This gives people deciding about whether to adopting XP, and those reviewing their current XP practices, a good place to look for topics. On the other hand, the conclusion part of the book is of very doubtful value, as nearly all its claims are not substantiated with the discussions before it, and in many cases conflicting. For a starter, it begins by saying that if your process is not broken, you shouldn't try introducing XP to an organization, and so a lot of projects shouldn't even consider. But earlier in the book it spent a lot of efforts explaining that, by measuring the staff turnover and project delivery delay, and by observing the staff morale, it is evident that the vast majority of organizations are using broken processes. And the tone about finding a first project is again very questionable. It basically says "if any of this long list of items cannot be satisfied, you shouldn't put XP into it as a first project. Yes, experienced XP teams can resolve all these problems, but it's not something you want in a first project, and I'll question whether the project is suitable for XP anyway." What it doesn't tell you directly, but instead only indirectly in earlier chapters, is that the project is likely to be just as unsuitable, or even more unsuitable, in any unmodified processes that have ever been designed. I echo Kent in his foreword that the book, being a critic on the XP process, should be read with critical eyes. Luckily, the conclusion part of the book is just two short chapters, although this put it into the list of books that you don't want to show to your manager, who is busy enough to be unlikely to read the whole of it.

One of the best XP books after Kent Beck's first XP book

This is an excellent book where the reader can see which problems there are with some of the XP practices as for example, On-Site Customer and how these problems can be solved.In addition, Pete McBreen develop conclusions about what the organization should take in consideration to implement the first time XP in one project.

If XP is the answer, what was the question?

I thoroughly enjoyed Pete McBreen's immoderate attack on heavy-duty software engineering practices in "Software Craftsmanship" and I had expected more of the same in "Questioning Extreme Programming". But McBreen comes across more like a schoolmaster reluctantly telling his favorite pupil that he only got a B. His point is that the conditions for XP to be successful are almost never found in nature: a dedicated customer, enthusiastic programmers, trusting management, an "expressive" language, a non-political office and a talented team "coach". He makes one other strong warning:"If the majority of your projects involve writing life- or safety-critical embedded software, please don't even think about using XP."That's a peculiar sentiment to express about a methodology whose main selling point is supposed to be that it produces a higher quality product. But the only claim that McBreen makes for XP is that programmers would have fought to introduce eXtreme methods to their shop have found the experience "fun". Ultimately, McBreen seems to be saying that XP is better than old-style software engineering, but so is almost every other modern software practice.Q. If XP is the answer, what was the question? A. What is the best way to write a program in *Smalltalk*?