Extreme Programming Explained : Embrace Change (2nd Edition)
by Kent Beck with Cynthia Andres

ISBN: 0321278658
Publisher: Addison-Wesley Professional
Pages: 224

Reading this book was a pleasant surprise. XP has been causing a lot of controversy over the last five years. Traditionalists dismiss XP as a bunch of cowboy coders riding their software towards anarchy. People with actual XP experience swear they don't want to work any other way. As the first edition of this book was the grand starting point, causing all these strong feelings and opinions, its content must be dynamite. At least I thought so and this is where my surprise came in; the dogma wasn't there! What I found was a collection of best-practices woven by an excellent author that really cares about producing the best software possible.

XP is more than technique. Although XP is probably best known for its practices such as pair-programming and test-first development, these practices have their roots in the values of XP. These values (communication, simplicity, feedback, and courage) are introduced early in the book. It then proceeds to illustrate how these values are guided by principles such as humanity and economics into practices.

The practices themselves are split into primary- and corollary-practices. The idea is that one can start to use any of the primary practices immediately, with added value, without any of the other practices in place. I agree. For example, some years ago I used test-first programming (a primary practice) on a large waterfall-like project with very good results. I guess it would be safe to suggest that other practices like an automatic build in ten minutes, including running all the tests, would improve the quality of most software projects. The other practices are all like this; simple and proven concepts clearly explained.

The corollary practices more or less require the primary practices to be in place. Failing to do so seems risky. Beck gives the example of starting to deploy daily (a corollary practice) without a low defect rate through primary practices like test-first, pair-programming and continuous integration. Such a strategy is likely to drown, and finally halt, the development in defect reports.

This first half of the book is worth its price alone! Then it gets even better. The second part focuses on the philosophy of XP. In "Taylorism and Software", the authors give their view on why having a separate QA is a mistake. An appealing alternative is highlighted in the following chapter, which gives a brief overview of the Toyota Production System (TPS). In TPS everyone is responsible for quality and waste in the form of defects and overproduction is continuously eliminated. The analogy to XP is clear and I think it helps shaping the understanding of what XP is all about.

It is my belief that most of the XP resistance may be derived from a lack of knowing what XP really is. In my opinion the name itself is misleading; had Beck chosen to label his philosophy of effective software development differently, much of the controversy would have been avoided. Even if the name stayed the same, this second edition takes a huge step towards giving XP larger acceptance from developers and managers.

Reviewed December 2005