Extreme programming never covinced me 🙂 I read Kent Beck’s book. I found it very well thought, with a good presentation. On some topics I agreed – unit test would have been a great thing to have in many projects I’ve worked on. Also some YAGNI (“You Aren’t Gonna Need It”) would have had helped sometimes. Also I found quite clever the idea of on-site customer, even if not so practical. Anyway I couldn’t imagine my programming life in pair. I have my rythm and I like to code alone. I’m ready to join colleagues if any of us would like to share thoughts or has some question, but programming was meant to be done alone :-).Another two points I wasn’t very comfortable with were no written requirements and no planning. I coulnd’t see how this kind of methodology could be applied to the environment where I’ve been working. We programmers strove to get specification and requirements in a written form. Our customers – artist and game designers were too fast in changing their minds, adding new requirements, and no so precise in their requests.
No plan conflicted with my idea of preparing for the future, choosing the right path to get to the goal.
Well, this book is a critique to the whole Extreme Programming, both on methodology and results. I recommend this book, even if its size could have been halved by removing parody songs (quite boring if you don’t know the original tunes) and reducing pointers to notes instead of having them occupy an inch of vertical space.
The starting point of the book is – where are XP results? Apparently the C3 project which was the springboard for the XP methodology was a blatant failure, so much that no one in Chrysler want to hear again of XP. C3 not only failed to hit the milestone (replacing the legacy payroll system before any chance of y2k bugs to manifest), but failed to produce a working system. According to the evidences that can be collected on internet and books, before being cancelled, C3 was able to handle only some 10% of the payroll it should have handled.
Nontheless many XP supporters advocate that this was a success, and that a project cancelled is not a failure, it’s just that the project stops to deliver value to its customer. XP propose other odd claims, such as, the planning doesn’t exist per se and XP project contracts should feature an ‘optional scope’. The customer should sign for a fixed amount of money and time, but it is not granted to have a result.
The book authors propose a fitting metaphore, they state that XP practices are like a circle of snakes. The XP requires a great effort to keep snakes at their places without anyone being harmed, but at the first distraction or relaxation, the snakes unravel biting the bystanders.
Some practices are identified as being more hard to follow closely. Also some roles have too much responsibilities such as the on-site customer (she is supposed to code unit test) and the coach (who is the warden of the XP verb, costantly taking care no one drift away from hortodoxy).
Also some risk are identified in the real world implementation of XP – likely a superficial management/customer would like the lack of up-front design and documentation, because this means that the programmers will start early to deliver something. But it is also likely that the very same superficial management would not apply unit test and costant refactor. In these situations all the XP methodology crumbles on itself. Many programmers had written to the book authors reporting their, usally bad, experiences in XP projects.
Another fitting observation is that basically what XP is doing is to enter maintenance mode from day 1. By looking at the traditional cost curve for a software project you notice that during this phase the curve is quite flat. And in fact what XP claims is to provide a flat cost curve. But it is the point where the project is most expensive. No one of the XP techniques can do anything to lower this.
Anther point that left me puzzled about XP was… pair programming. According to XP every activity has to performed in pairs. To support this claim Kent is ready to offer some references. XP refactored run a bit of investigation and discovered that the test (yes, just one) supporting that two heads paired have a productivity greater that a non-paired duo, was conducted on college students. Obsiously the results cannot be related to experienced or senior programmers.
The book closes with a refactoring of the XP methodology. I would say this is the least interesting part, since it turns out to be just another methodology not so different by the agile ones proposed in other book of software engineering.
To sum it up, I think you better read this before deciding to enter an XP project, and definitively you MUST read this book before running your own project with XP methodology.