Extreme Programming in Practice (XP) [Paperback]

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

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