Customer Reviews

Questioning Extreme Programming

5 star:		(1)
4 star:		(3)
3 star:		(6)
2 star:		(1)
1 star:		(0)

 

 

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.

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.

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.

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.

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.

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*?

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.

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

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.

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.