Rating: 
Summary: A thoughtful look at XP in practice
Review: 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.
Rating:
Summary: A thoughtful look at XP in practice
Review: 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.
Rating: 
Summary: Follow an XP project from start to finish
Review: 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.
Rating: 
Summary: A Case Study, Not a Guide
Review: I bought this because I was looking into the possibility of using XP with my team of engineers. While other XP books describe the philosophy and practice of it, this is a "diary" of one team's first attempt with XP. It was interesting enough, but their projects and work environment were not sufficiently like ours to make it truly useful. The project in this book is a very small website registration system - not exactly rocket science. If you're already using XP and would like to see how someone else is doing it, then this may be of interest to you. If you are looking for information on getting XP going yourself, look elsewhere.
Rating:
Summary: A Case Study, Not a Guide
Review: I bought this because I was looking into the possibility of using XP with my team of engineers. While other XP books describe the philosophy and practice of it, this is a "diary" of one team's first attempt with XP. It was interesting enough, but their projects and work environment were not sufficiently like ours to make it truly useful. The project in this book is a very small website registration system - not exactly rocket science. If you're already using XP and would like to see how someone else is doing it, then this may be of interest to you. If you are looking for information on getting XP going yourself, look elsewhere.
Rating: 
Summary: Not Much Practical Information
Review: I bought this book mainly because XP theory is everywhere, but examples of applying it to the development process are pretty scarce. I admit I was also persuaded by the authors' reputations. The book is very disappointing. It reads like a Socratic dialogue, only Socrates forgot to show up and left it to two of his freshman students to hash things out. Needless to say, they bumble along and in the meantime do not enlighten the reader much. If you waste your time reading this book, you'll probably realize that you're a more disciplined developer than you thought. To some people that might be worth the [PRICE]. For good practical information on XP coding and testing, I highly recommend Rick Hightower's book "Java Tools for Extreme Programming". This is a great guide to using open source tools like Ant and JUnit to do XP development in a Java shop. Might be too practical for Socrates to have written, but Aristotle would have loved it.
Rating:
Summary: Well below expectations based on the authors' names
Review: I fully agree with points of Ken Egervary's review - and would like to add a few more points (related to technical as well as other issues) in no particular order of importance: - while it is OK to use a new terminology to describe old concepts, I don't think it is a good idea to make readers believe that these very concepts are new and unique to XP. I refer to "spikes" and "spoofing" - which are concepts as old as programming itself; - of course diagrams are easier to understand than code unless the there is very little of very simple code. Should we forget about UML? What about leaving clients a bit more documentation than source code and API docs?; - concept of refactoring seem to be used only in relation to coding - what about refactoring of analysis and design models (not that there are any in the book)? In fact, there seem to be no analysis and design anywhere in the book - although "backing into the code" concept does sound like a poor-man version of analysis to me; - arguable concepts such as use of return codes versus exceptions are introduced in by-the-by manner without any argumentation. One could strongly argue that using exceptions for error-handling is a better option because: 1) unlike return code, they cannot be ignored and must be handled or at least consciously ignored; 2) generic error handling and logging mechanisms can be easily implemented especially considering that exceptions - unlike return codes - are automatically propagated and therefore can be handled at different levels as desired; Etc. - the most appalling mistake of having instance-level variables in the servlets that do NOT implement SingleThreadModel interface (such as, for example, use of private variables request, response, email and url in ForgotPassword servlet). This is NOT thread-safe - and a 5 min "spike" would convince you that this is so. Good thing it was not a project where data more sensitive than somebody's password are mailed to the users who happened to access the same servlet at the same time! Etc., etc.
Rating:
Summary: Useful Introduction into XP
Review: I have read the reviews and the book. Let me start out by saying that the bad reviews for this book in my opinion are incorrect. I find that the reviews have focused on what the book does not explain. I found that the material that was covered in the book was covered well and I found it interesting to read. True, it does not cover how XP was done on a project with 12 programmers and many customers and a project of 1-year duration. Should this book be faulted for the things it does not explain? Also, the book is in fact XP in Practice not anything else. So the review that stated that it did not cover refactoring of design and analysis models is somewhat off-based, since XP does not talk about refactoring of design or analysis models. Other points made by various reviews are also interesting. In Ken's review he said 4 hours to make a database table is ridiculous. It is, but that is not what the programmers did in those 4 hours. They created the table, wrote the JDBC code to access the table and wrote tests to verify the implementation. I guess Ken did not bother to read that part of the book. Ken's review also stated that the programmers were incompetent since they forgot the password field. Well, Ken must be the only one of us who has never forgotten a column in a database table. If that were the definition of incompetence I would venture a guess that there are a fair amount of us who are incompetent. Lastly the technical error regarding the use of instance variables in servlets is a very common mistake. I have seen this error many times looking at servlet code on my consulting jobs. This does not excuse the mistake but it does happen in systems that are put into production. Overall, I looked at the book for what it was providing instead of expecting so much more. I feel that it provides a useful introduction into what it is like to do an XP project. It also shows some of the downsides of not doing all the practices and what the penalty might be.
Rating:
Summary: Fine book to start, but reading needs to be complemented
Review: 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.
Rating:
Summary: An ideal book to have in your hand when trying to explain XP
Review: 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.
| 
