Extreme Programming (XP) has been the subject of heated debate since its arrival on the programming scene in 1998—understandably so, as it contradicts many traditional software development beliefs. We¿ve heard success stories about sweeping changes made to organizations as a result of XP. We’ve read books about how this approach can work for our teams. However, are there times when XP isn’t appropriate? There are certainly instances when making the leap to XP could potentially jeopardize a whole project. What’s missing from all of this rhetoric? Witness Pete McBreen, software craftsman, examine the issue from both sides.

In Questioning Extreme Programming, the author helps you examine and answer the following questions:

• Is the cost of change really low?

• Does XP allow proper testing?

• Does XP make sense?

• Is XP a return to the dark ages?

• Can we adopt XP practices for other approaches?

• 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 informed decisions about Extreme Programming, and whether it is suitable for their organization. Readers will also be able to determine whether Extreme Programming is inappropriate for a particular project. The author challenges you to look past the hype and start asking the hard questions about how software is built. Discover for yourself.

0201844575B07092002

Amazon.com® Reader Reviews (Ranked by Helpfulness)

Average Amazon.com® Rating:  Based on 11 Ratings

I am as skeptical about XP after reading as I was before - 2006-05-29
Reviewer Rating:
Given the evangelical nature of many of the people practicing eXtreme Programming (XP), it is natural that sensible people step forward to challenge their claims. That is the stated purpose of this book, but in many ways McBreen doesn't quite reach the level of honest critic.
Chapter 21, where the topic is "Transitioning Away From Extreme Programming", demonstrates this. He states, "(when transitioning) . . . you are likely to face resistance from your XP teams because their sense of control over their work that Extreme Programming gives is very addictive." He also restates something mentioned several times, "This (an XP project) is the best project we have ever worked on." Finally, to make a point about the problems of transitioning away from XP, he begins with "Assuming for a moment that Extreme Programming is going to continue to grow in popularity . . . " These are statements of someone who is convinced that XP works very well and not those of a skeptic.
The book starts with an explanation of what software development methodologies are. The next section is a description of what XP is, the simple core principles are listed with examples of what the principles are, how they are applied in XP and the problem that the XP application is trying to avoid. This section is well done and could serve as an introduction to XP.
Part IV, "Questioning XP concepts" is where most people will express their doubts. The first chapter of this section is "The Source Code Is the Design?" and the main premise is that the source code is the design document. As skeptical scientists often say, "extraordinary claims require extraordinary evidence." I have yet to see conclusive evidence of this and that is after I read this book. To say that the finished product is the design document is to go against the evidence. Large projects require a great deal of thought about how things should be put together. While I am a firm believer in evolutionary development leading to complexity, McBreen did not convince me that the XP way can evolve a design from the development of source code.
After reading this book, I came away still in possession of all the doubts that I had about XP before I started reading it. McBreen appears to convince himself that XP works and works well. However, in my case my level of skepticism was essentially unchanged.

Hmmmm - 2007-12-07
Reviewer Rating:
I finished the book but it took me a long time. It's nice to see that someone dears to question extreme programming and write a book about it in the `extreme programming' series. I personally feel the same with extreme programming. Lots of the practices are very sensible, especially for programmers. My favorites are: Test first programming, Pair programming, and Refactoring. But when we look at the design-part, I feel a bit less confident about XP. I think some basic architecture needs to be in place and that that won't be created by refactoring alone. Pete McBreen takes all XP practices one by one and talks about them. I bought this book because I had good experiences with the earlier books in the series. But this one I had difficulty to get through and it took me a long time to read it completely. Is this because the book is bad quality? I don't know, I had a few problems with it:


1. It's assumed to answer the question: is XP good for your project. Well there is no real answer. It's just for you to find out like it was with the first books in the series

2. All attacks on the xp were a bit fuzzy like Pete doesn't support his own statements

3. I'm more in favor of books that explain things using a diagram and makes me wanna go further because the next chapter has some interesting stuff...

Valuable read for the XP/Agile devotee - 2006-10-27
Reviewer Rating:
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 - 2005-02-26
Reviewer Rating:
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 - 2004-06-26
Reviewer Rating:
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.

Browse Similar Topics

Top Level Categories:
Software Engineering

Sub-Categories:
Software Engineering > Extreme Programming