Rating: 
Summary: Don't buy it (my newer review)
Review: I've read 100 pages into the book so far, and I would have to say it is not that amazing. The book basically runs through a project that they did using XP and they share their stories and experiences. The project they talk about is very typical to most websites (a way to register, login, get a forgotten password, etc.) I was very surprised to see that the project was estimated at 25 days. Even some functions like creating one table was estimated to take 4 hours. It seemed that the developers were not very capable individuals, or perhaps they simply expected an incompetent crowd to be reading the book. There is actual proof of my claim too since even taking their 4 hours to make the table, they had still forgetton to create the 'password' attribute within the table. They realized this when they tested their code. Leaving out those architectural details are we? I also did not agree with the book's statements in not considering architectural details - in fact none were considered at all, even when it came down to iteration planning. I know this is an element of the XP methodology, but some of their reasons for not doing a model indicated that they didn't understand the problem enough. The only valid reason I found for not planning for future change was that the customer may not request the features required by the more robust architecture. That is valid, but let's think about repeat business. Let's assume they come back in a year's time to make those changes and you'll probably be thanking yourself you did make it scalable. It's less time for you and your staff and less you have to charge your client. Everyone is much happier. Another instance of terrible design is on page 103. They used an Adapter pattern (found in the GoF book) to adapt a method from their database class to another class with the identical name for the method. Well, as far as I know, that is NOT why you use the Adapter pattern. Adapter is used when you have an API that doesn't follow an interface used throughout the application. Programmer's use the Adapter to make an interface conform to a new one. Well, in using the Adapter in the book's example, they are merely delegating a task, not adapting an unfamiliar interface. Even worse - What was the method called? - findUserByEmail() found inside the Database connection object (connecting and closing the DBMS). Why is it there? No architecture thinking done at all! It should have been placed in a UserFactory or User Data Access Object class in the first place (the book refers to it as its User class). They would have avoided this problem (and misuse of a pattern) altogether. One more thing about architecture. There was a case where they had made 2 servlets, both containing almost identical code. With XP's refactoring, they had created a base class and inherited appropriately. After restructuring their test cases and refactoring several times, they finally got it right. Wouldn't a solid design have been better? The book states that up-front design is bad. Well, I know the point of XP is to not follow a hardcore design document for the entire project because you realize that customer requirements are voltatile. But, shouldn't we at least come up with a smaller design document for each iteration? I mean, it's not practical for a customer to interrupt an interation - in fact it's a rule the customer cannot do according to this book. I still say, if you are not going to plan your system, at least plan the architecture for a 'subset' of the system - i.e. in each iteration plan. Even after reviewing the code, I thought some elementary coders were at work. There was a part in the book where they either had to convert some pages from ASP to JSP if they wanted the banner to be the same, but they could have simply encapsulated the banner into a file and included it in both the ASP and JSP versions, saving their estimated implementation time of 5 days. The book has it's morals, but the project is by far too small to be a true testiment to the success of XP. This kind of project could have easily been done by one competent person sitting at their machine for 2 days, and I do believe it would have been done much better architecturally as well. There is no design pattern work, no architecture and clearly reading their programming flaws and decision making failures, no wonder they estimated a completion date of 25 days. I gather that XP is still good for projects with much greater complexity than this registration system, but the book does a bad job explaining that. It seems XP is good for programmers that need other support to compensate for their lack of ability to be a good programmer - I know that is not true when it comes to pair programming, but this book isn't doing a good job of convincing me otherwise. I haven't read any of the other XP books - but stay away from this one unless you want to read bad software designs and coding examples, non-realistic programming errors, and poorly made decisions. It's not XP that would have helped this team, a new set of programmers and architects would have done better. If you simply want to learn about XP, stay away from this book. If you want to learn about failures on projects and actually learn something, read the Mythical Man Month. If you want to spend [price], throw it into lottery tickets, you'll learn about 'wasting money' and how to better spend it. If you need to learn XP.... try another XP book in the series.
Rating: 
Summary: Not introductory XP book and not a great book at that
Review: I've read 100 pages into the book so far, and I'd have to say it is not that amazing. The project they talk about is a registration system, typical to most websites (a way to register, login, get a forgetten password, etc.) I was very surprised to see that the project was estimated at 25 days. Even some functions like creating 1 table was estimated to take 4 hours. It seemed the developers were not very capable individuals or simply expected a not so capable crowd to be reading the book. I also did not agree with the books statements to not consider architectural details - in fact none were considered at all, even when it came down to iteration planning. I know this is an element of XP, but some of their reasons for not doing a model were very good signs that they didn't understand the problem enough. The only valid reason I found was the customer may not request the features required by the more robust architecture - but they may even come back in a year's time and you'll probably be thanking yourself you did make it scalable. Even after reviewing the code, I thought some elementary coders were at work. There was a part in the book where they either had to convert some pages from ASP to JSP if they wanted the banner to be the same, but they could have simply encapsulated the banner into a file and included it in both the ASP and JSP versions saving their estimated implementation time of 5 days. The book has it's morals, but the project is by far too small to be a true testiment to the success of XP - this kind of thing can be done by one competent person sitting at their machine in a basement for a 2 days, and I do believe it would have been done much better. There is no pattern work, no architecture and clearly reading their programming flaws and decision making failures, no wonder they estimated a completion date of 25 days. I gather that XP is still good for projects 40x the complexity of this registration system, but the book does a bad job explaining that. It seems XP is good for programmers that need support to compensate for their lack of ability to be a good programmer - I know that's not true though, but this book isn't doing a good job of convincing me otherwise. I haven't read any of the other XP books - but stay away from this one unless you want to read bad design and coding examples, non-realistic programming errors and poorly made decisions. It's not XP that would have helped this team, a new set of programmers and architects would have done better. If you simply want to learn about XP, stay away from this book.
Rating: 
Summary: Terrible Book
Review: I've read a few reviews on this book and it's just terrible. Like come on guys, can't you get it right the first time? Ken Edgervari's review was very sound, but I thought it would be good still, ya know? This book is all about code. It's like 10% XP. I know it's not supposed to teach XP, but this is like 50-60% source verbatim. I can't believe people actually enjoyed this book. The only people that will enjoy this book are people that want to see code written for programs that are larger than the ones they are forced to write at in a highschool programming class or in university - where they teach you nothing anyway. If you are really stuck and can't figure out how to code a registration system - the code is here! Just copy it out and type away in your edit.com (since you probably aren't smart enough to use an IDE) and compile away. The author's don't care - heck that's what the book is for, teaching how to make registration systems and POORLY at that! Seriously, this book doesn't talk about team dynamics in XP, how managers view xp and work with it.. it's just a project done by 3 people simultaneously where 2 other people jump in as 2 others leave. Not very realistic, but I guess it happened. I think a book like this should be written for like 8-10 programmers, a business manager, and probably 1-2 business customers. If you could explain team dynamics, the pragmatics of the xp software process, explain how people had to adapt and problems with adapting, explaining the benefits gained from xp programmers using XP all the time in their careers, common problems associated with communication, benefits with project communication, other problems in the project environment (not in the code by in all events that are untaken with a software project) and other stuff that typically, but where xp changes the typical events, then this book would be useful. This book is everything in code, but that. But it didn't, so thousands of people bought a crappy book and the 2 well respected authors made a killing once again. This time the book wasn't good - so I hope they make less of a killing next time. I don't like buying really crappy books. I know others don't either. Heck, I know James W. Newkirk and Robert C. Martin probably don't, so why put this crap out? DO people a favour, release a 2nd edition and redeem yourselves or I will.
Rating: 
Summary: Learn by example
Review: 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.
Rating:
Summary: A pitty, especially from great authors
Review: Maybe I should give a better rating to this book, but both authors have already wrote very good books & papers, so...
Honestly, I don't understand why they write this book. The experiment doesn't reflect the field realities (2 gurus working together, for an internal project !), the book is rather short and filled with uneeded source code (if I want it, I get a Java book). At the end of the book, I didn't get the impression to have learn something valuable. My advice is to prefer (for the same target) "Extreme programming installed" which gives a true return on experience about XP, or even "Extreme Programming Explored",called "the XP FAQ" by myself.
Bob & James, you are great guys. Really ! I lot of your writtings is more than valuable, and I got them. That's why I owned this book blindly. I'm afraid to say that it was my "disapointment of the year". Sorry.
Rating:
Summary: I expected better
Review: My biggest disappointment is that the authors did not write automated acceptance tests, which is one of the XP practices that people who are seriously trying to adopt XP have the most questions about. The fact that their development work was sporadic also did not help present the 'normal' usage of XP. Otherwise it is not a bad book, but I would buy all the other XP books first before buying this one -- particularly "Extreme Programming Installed", "Planning Extreme Programming", and "Extreme Programming Explained".
Rating:
Summary: ok, not as bad as some say
Review: On the plus side they discussed an actual project and listed their mistakes and how we could avoid them. But following all the vast coding examples was tedious, esp. if you aren't familiar with Java web programming. For me the book was very short and very over priced for its small content (excluding the source code which makes up a third or more ofr the book). The XP Explained series is decent but there is a lot of overlap and all the books are too short considering thier high price tag.
Rating:
Summary: Easy to read introduction to XP
Review: The book is written as a story describing a small XP project which makes it easy to read from start to end. It gives a good view of how XP can be applied in a certain kind of project and therefore demonstrates some of the ideas of XP.
I see this book as a "Hello, world!" for XP. It gives a simple example to get started, but it is far from an exhaustive description on how to apply XP in real projects.
Rating:
Summary: Much better books on XP than this one
Review: This book chronicles the authors' first attempt at using XP (on a three week project). The real gist of the book is to emphasize the importance of test-first programming. However, the authors don't explain how to set it up or give much information on how to use test-first tools. In the end you are given some pointers on doing XP development. Kent Beck's or Ronald Jeffries' books do a much better job of explaining the XP methodology. Get one of those books instead.
Rating: 
Summary: Great XP Reference
Review: This is a great book to keep at your desk while pair programming. It gives enough of a real world example to be helpful. It also includes a simple example of database spoofing which is an important XP concept but isn't obvious when you first try XP.
| 
