Questioning Extreme Programming

Rating:
Summary: explains XP jargon, but doesn't support its assertions
Review: I found the book Questioning Extreme Programming to provide a good explanation of XP for people who don't already know its jargon.

However, Pete's assertion that XP only works in a certain niche of possible project-types isn't supported in the book -- the assertion is made many times, but no real evidence is presented. Since there are many successful projects out there doing XP, the niche must not be as small as Pete says.

I agree with one point from another (not yet published) book on agile software development: XP can provide a great improvement in software quality in those companies that don't already have a good development process. If your company has a good development process with acceptible agility and good enough results, you don't need to change what you do.

Rating:
Summary: If XP is the answer, what was the question?
Review: 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*?

Rating:
Summary: Good except the conclusion
Review: 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.

Rating:
Summary: hmmmmmmmm.. OK!
Review: In Questioning Extreme Programming, the book helps you answer such questions:

* Is the cost of change really low?
* Does XP do proper testing?
* Does XP make sense?
* Is XP a return to the dark ages?
* What can other approaches learn from XP?
* Do you need process improvement or process change ?
* Why are developers so zealous about adopting XP?
* Is XP suitable for your projects?
* What is the next step after Extreme Programming?

After reading this thought-provoking book, software developers can make an informed decision about Extreme Programming, and whether it is suitable for their organization. Readers will also be able to determine whether Extreme Programming is inappropriate for their project. Discover for yourself. Look past the hype, and start asking the hard questions about how software is built!

Rating:
Summary: OK. It finally made a book.
Review: Most programmers have used some form of XP over the years. Actually it dates back to times when there was no software development lifecycles. Am I dating myself? However, it can work in some circumstances with smaller projects and very thorough, disciplined and highly technical programmers. For the most part however, I find that it causes a lot of extra re-work, delays getting the finished project implemented as the user wants it, and uses a lot of time re-building, re-testing, excessive version control, re-implementing, changes, changes, changes, and lots of scope creep and gold-plating. Not only that but when I was programming it was not beneficial to have another programmer or anyone breathing down my neck. I need complete focus and concentration for long periods of time. It seems that things like this always tend to run in circles. With the younger generations trying what the older generations tried and then realizing you cannot skip the up-front work.

Rating:
Summary: OK. It finally made a book.
Review: Most programmers have used some form of XP over the years. Actually it dates back to times when there was no software development lifecycles. Am I dating myself? However, it can work in some circumstances with smaller projects and very thorough, disciplined and highly technical programmers. For the most part however, I find that it causes a lot of extra re-work, delays getting the finished project implemented as the user wants it, and uses a lot of time re-building, re-testing, excessive version control, re-implementing, changes, changes, changes, and lots of scope creep and gold-plating. Not only that but when I was programming it was not beneficial to have another programmer or anyone breathing down my neck. I need complete focus and concentration for long periods of time. It seems that things like this always tend to run in circles. With the younger generations trying what the older generations tried and then realizing you cannot skip the up-front work.

Rating:
Summary: valuable for coaches; needs more valid research
Review: Some quotes from a longer review that I wrote:

"presents many good challenges that need to be addressed"

"Questioning XP did not appear to be backed by enough meaningful research or experience to provide a truly honest critique of XP. Its conclusions did not seem to be in line with the evidence presented in the rest of the book. However, I do recommend it for XP coaches--it does provide a thorough awareness of the issues that will be faced on an XP effort."

A complete review is available at xprogramming.com.

Rating:
Summary: Entertaining debunking of XP mythos, but not concrete enough
Review: The biggest thing I liked was that it didn't just focus on XP, but also hit on a lot of other methodologies, doing some comparisons and contrasts. Expect to understand what all the hubub is about after going through it, without needing to buy into any of the other Agile background books first. You will probably also be able to take away a high-level piece or two of advice from it.

It's not something I would purchase, though, because it stays pretty high-level through much of the book, and doesn't really have much reference material value. I was also a bit dismayed that he hadn't run a project with XP yet. He cheerfully admitted it in the introduction, and his reviewers were all of the hardcore folks associated with XP; however, that still gave me the same feeling as I would get reading a book entitled Questioning Low-Fat Recipies from the Two Fat Ladies, where they claimed they'd never tried any. Sure, they're FAR better cooks than I am. And probably see more different types of recipies in a given week than I will in a year. But I just would get the feeling I might be missing the whole picture and that too many of the judgements are value-laden and not backed by concrete examples of things that went wrong in his XP projects.

Also, it was weird for a book this small, but I felt like it repeated itself in a couple of the 'summary' end of chapter sections, especially near the end of the book.

Rating:
Summary: One of the best XP books after Kent Beck's first XP book
Review: 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.