Extreme Programming in Practice

I have spoken and corresponded with a lot of people about Extreme Programming (XP). I've encouraged them to read "Extreme Programming Explained - Embrace Change" and the other XP books that followed it. I've shown them some products produced using XP techniques. But somehow it's always been really hard to explain. Now I know what was missing. I needed this book.It's not a big book, but it powerfully expresses how XP works and, more importantly, what it feels like. The authors kept detailed notes when they first implemented Extreme Programming with a fairly simple web/Java/database project, and they give a blow-by-blow account of it. This is not an idealised case study; they made plenty of mistakes, but they show how the team learned from them. All the Java code for the project is shown as it is refactored. All the user story cards and task/time tracking are shown as the project progresses.If you have read or heard about XP but want to know what it's really like, this is the book. It's not much of a reference, but its a terrific introduction.

I have recently finished reading the book and I'm going through it again as I develop my first XP project. I wasn't very familiar with XP before reading it but still I was able to understand the principles of XP complementing the reading with articles from the web.Although they try to justify their decisions and explain their mistakes, I would like it to have more explanations about why they make some decisions and not others. I have found also that some things in their project are a bit "ideal" and not as "real" as in the projects and organizations I've worked in. For example, their times don't seem to be very realistic as they never spend more time than they planned in their first XP project.

Extreme Progamming or XP is proving to be a very useful blueprint to follow in the construction of software. In this book, you are led through a project as the authors build an online registration page using the XP principles. Of course they work, and the site functions once they are done. It is true that XP is a solid process for building smaller projects, of which this is one, and that the authors do a good job in explaining how they performed their tasks within the constraints of the XP model. Finally, the authors quite naturally tout the positive aspects of using XP to develop software. The problem that I have with the book is the point where the authors begin. In chapter 1, they briefly describe how they tried and failed to build the project the first time. In closing the chapter, they state: "We realized we needed to employ a process for making changes to our web site. In hindsight: Duh." I have no problem with this, but note that anything that forces you to plan would be a success after the initial approach. To say that we had no plan and failed and then used the XP plan and succeeded is weak evidence in favor of XP. Given the mounting evidence, few doubt that XP will steer you to success in projects on the smaller end of the scale. The key question is: how does it compare to other processes that you could use? That is the one question that all project managers are really interested in and one that I wish they would have tackled. A book like that would be something to rave about. That aside, this is a book where you can learn the principles of XP and follow how it is used from the tickle in the head to the robust active page. However, that only makes it good and not great.

As a developer who has used XP in a somewhat patchwork fashion, I've been looking forward to this book for some time. My interest was mostly driven by an article "Uncle Bob" Martin co-wrote a few months back about a pair-programming development episode in which the pair wrote a small program to score bowling games. The article was written as a dialogue between the two programmers and was very well done.Once again, they have used a real project (actually in production on the Object Mentor website) to illustrate what development under XP is really like.This book has been written in the style of the other books in the XP series: it is brief, conversational in tone, and to the point. It departs from the other books in the series by including quite a few pages of code. It's also reasonable to say that the authors are assuming the reader is somewhat familiar with XP, and I'd say it is a companion piece to the XP explained book by Kent Beck (or perhaps the extremeprogramming.org website).I imagine the authors agonized over how much detail to go into with this book. The purpose of the book is to illustrate XP in practice (not to teach servlet programming), and I'd say the level of detail they went into is just about right -- they describe their experience over the course of a one-week iteration, down to the level of their daily tasks and the interactions (even one verbatim dialogue) with their client. The authors do an exceptional job of describing the *is* of XP without being pedantic or cute, which has been a significant flaw in a lot of the XP advocacy I've seen on the web. The book is well written, and the code is good...I only saw one technical error. Overall, an excellent book. More than ever, it makes me want to try a "pure" XP approach on one small project to see if I can really make a go of it.

It's actually hard to say anything more than Martin Fowler's foreward. This book is an attempt to convey the experience of working the XP way into book form. What's most interesting is that the mistakes and hiccups of the small project are described and not just hidden away. The message is that real projects are almost never smooth rides. XP is one way to deal with that fact.