Having practiced XP, I particularly like two chapters in this book, one on XP in a nuthouse which is a good read for someone who is new to XP to get a quick understanding of the XP concept and the next one is the chapter on XP refactored in which the authors point out good features of XP along with their own best practices added and ideas that may make XP better.
This book is an extreme view of Extreme programming. The authors have criticized almost every aspect of Extreme programming. Any developer thinking of following the methodology would be discouraged to do so if they came across this book first.
They take a very rigid stand on refactoring, picturing as if XP programmers are in a constant refactoring frenzy for no good reason. Lack of initial design has been pointed out as being responsible for lot of rework. Release early, release often concept has been shown to increase the developer's concern of whether it will integrate into the system and satisfy all the tests or not.
They point out that XP is not scalable and is only suitable for small projects. Though most of the XP projects are small, I know the above statement is not entirely true as I heard a success story of a big project which was migrating and had a strict production deadline to meet which it did.
The authors picked examples from instances where the coders did not take care of situations. For example, they comment on unit tests saying that unit tests are stand alone in XP and often left databases dirty. The developer in that instance may not have had roll back statements in the test which is why the database was left dirty and hence it is not a flaw with XP methodology but a flaw with the way it was implemented.
By the end of the book, the authors refactor XP and delineate the pros and cons of each XP component in which they mention the following points:
* Pair programming should not be constant or mandatory
* Programmers should design
* Programmers should write their own tests
* Instead of continuous design, we should follow frequent design
* 40 hr weeks are not feasible as sometimes developers have to work overtime to meet deadlines
* Coding, testing, listening and designing of XP are worth salvaging
* Iterations should be one month long
* Test first design should complement the design but should not drive it
* Use a combination of requirements and use cases instead of user stories
* Project velocity should be measured in terms of formal requirements completed per iteration rather than user stories per iteration
Overall, I thought it was a fairly good though quick read for me
An expanded blog comment
I'm writing my thesis that reviews and debates one specific Agile aspect.
Hoped to find something valuable here, but got very surprised instead...of how certain books could get published at all.
It doesn't elaborate much on XP, but is an expanded version of what should have been a vandalic comment in an XP blog.
I can be sarcastic speaking about the childish jokes, but had enough sneering with the book already. Is a pity the name looks interesting, somebody may have wanted to use it for serious purposes.
Great insight, but enough of the Beatles parody songs
The most amusing (and damning) part of this book's message are the quoted statements from the XP prophets. They are ridiculous and hilarious.
The authors well document these statements, although using references of messages posted to newsgroups is a little on the border of legitimate. The statements quoted from the prophets' books are quite adequate.
Unfortunately the authors don't let that humor stand on its own, and they try to write mock Monty Python skits and parody Beatles songs with XP lyrics. This is where the book falls flat.
Amusing but not a serious questioning of XP
I read the book before I read the reviews, and I have to say that I found most of the more crtical reviews of this book were right on the nail. As a project manager with 19 odd years experience, the last 4 years of which have involved managing teams transitioning to Agile Practices and usually managing team technology skillset transitions at the same time, I have to say I like some XP practices but not XP as THE guiding process/methodology for a team. Working for a global IT services organisation, I'm fortunately in the position of being able to heavily influence the methodolog(ies) my projects follow, and I do consistently use selected XP practices and find them useful (my bias is exposed....).
With that said, I was looking forward to a good thorough critique of XP when I started on this book - but I really do find the satrical approach overdone. To be sure, it was entertaining the first few times, but after that the tone begins to pall. I did enjoy some of what the authors write, some of their criticsms I believe are valid, but the ongoing attempts to be funny and the overdone attacks on XP undermine what could have been a useful critique of XP. McBreen's "Questioning Extreme Programming" book is a far better examination of XP, although to my mind he doesn't dig deep enough into some of the problems that XP teams seem to experience (and I speak from hearsay here, largely from developers I've worked with who have come from teams where XP was THE only process followed).
That said,I enjoyed reading the book. Just wouldn't recommend it to anyone as a serious critique of XP.
Cut to the core of XP's glaring defects
When i first read R Martin's book on agile/xp, the first thing that jumped out at me was Pair Programming (PP): it's the most stupid idea ever!
This book did an excellent job to show why PP was bad and how it creates problems rather than solve them. It also exposed warped statistics that was used to push PP. I esp. like this quote in the book: too many cooks spoil the broth.
Unlike other fervent attacks on XP, this book provided many constructive suggestions that showed that software development is a complex business and as such cannot be addressed using a single methodology like XP.
