Customer Reviews

Extreme Programming in Practice

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

 

 

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

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.

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.

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.

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.

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.

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.

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.

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.