This book explores the XP hype and discusses the problems. In the end the best parts of XP will be used in the writers own software engineering process.

The first part gives a summary of the XP process and the problems with the c3 project of Daimler-Chrysler. This is the project that is talking about to prove Xp can be used in larger projects. By using excerpts from a number of wiki resources they tend to show the problems with the c3 project. The following resources are good to read.

http://c2.com/cgi/wiki?CthreeProjectTerminated

Interesting wiki page, fun to read. But the finesse is at the end. In fact the most important part of the part is rewritten about 15 times:

"Near as I can tell the fundamental problem was that the GoldOwner and GoalDonor weren't the same. The customer feeding stories to the team didn't care about the same things as the managers evaluating the team's performance. This is bad, and we know it's bad, but it was masked early because we happened to have a customer who was precisely aligned with the IT managers. The new customers who came on wanted tweaks to the existing system more than they wanted to turn off the next mainframe payroll system. IT management wanted to turn off the next mainframe payroll system. Game over. Or not, we'll see..." -- KentBeck

The discussion whether the project is a success or not is hard. It did come to results within 11 months that are still used. Other projects trying the same did not succeed at all. However 4 years of hard work did not nearly reach the state of providing the complete system. I guess Xp is hard to be used in a project that takes longer than about 3-4 months. But the biggest problem is the lack of design and specifications. I believe in the goal oriented design and the use of personas. See the book "The inmates are running the asylum".

The stuff of Xp that is very good to use:
test-driven development, continuous Integration, Coding standards, release soon and often, interaction design and pair programming.

One important remark for pair programming, use it wise. I have the same opinion as the writers of the book. Only use pair programming for the hard part of your system.

The following excerpt from the book made me laugh, but I think it is very close to the truth.
"XP is a methodology creates by programmers who are sick of management telling them that they can no longer just code, but they must follow a formal methodology. XP's main tenets are all very programmer-centric and often fail to consider the larger scope of a software development project."

This something we have to learn from within our gridshore philosophy. We must take care not to make it a programmers game. We need to have good designers (interaction, interface and software) as well.

The final chapter of part one discusses what can go wrong with the XP process. This chapter introduces the concept of the circle of snakes. Each snake represents one the practices of xp. What makes it interesting is that each snake can only be made safe by daisy chaining it to the next snake. I'll give an example by one of the snakes.

Emergent design means that very little time is spent designing the system before coding begins. The overall design and architecture will morph many times in the course of the project. But the lack of significant upfront design is considered "safe" because the code is being constantly refactored.

Why is this rng so interesting, since failing with one of the snakes makes the complete process instable. It is very hard do all snakes right, therefore the process is hard. A process should not be hard to use, if one of the snakes fails the process should have contingency build in.

One of the things they keep referring to is throwing yuor code away at 5 oclock if it does not integrate. see the following url for an image of the process
http://xp123.com/xplor/xp0006/index.shtml

I am curious what the book will bring in the following parts, more to follow ...