"Extreme Programming Explained: Embrace Change," by Kent Beck

Pros: Clear overview of Extreme Programming
Cons: Some assumptions should be better supported
Rating: 4 out of 5

When it first appeared, Extreme Programmming (XP), generated a great deal of passionate debate (read as: violent argument) among software engineers. The bloodshed has quieted, though my own experience with this debate suggests that we’ve merely traded our rifles and mortars for cloaks and daggers. No matter which side has conscripted you – or if you’ve remained neutral – this book is the starting point for learning about XP.

Kent Beck’s book, Extreme Programming Explained: Embrace Change, provides a solid overview of where the XPers are coming from, how they got here, where they’re going, and why. Whether you come away agreeing or disagreeing with the ideas presented in the book, I recommend it as worth the read.

The author did something right (at least, to my tastes) up front. The first quarter of the book defines the problem to be solved. Too often software process books begin with hand waving statistics about the number of projects that fail to deliver on time, on budget, or at all. Then a miracle occurs, and out pops the subject matter of the book as a solution. By contrast, Mr. Beck walks through the economics of software project management, building a case for how XP addresses the business problems of software development. Two key observations he makes are that 1) flexibility to accomodate delayed (and changing) decision-making is a strong benefit and 2) managing scope is a powerful lever for keeping a project under control.

The remainder of the book describes the processes and practices that make up XP. The text is intentionally heavy on background and theory, light on detail. The intent is to provide the rationale behind XP, not a guide to implementing the process. For example, the chapter on development covers continuous integration, collective ownership, pair programming, and more in five pages. If you’re looking to put XP into practice right away, this may be frustrating: the first time a colleague and I tried sitting at a single workstation and working together… well, take my word for it, pair programming it was not.

The book does explain how each practice fits into the whole of XP and why each is a necessary, mutually reinforcing part of the whole. The chain of reasoning is clear and easy to understand at every step. Moreover, the author has a lively style that makes the book an entertaining read. There are places where where the book comes across as a hard sell, and I can imagine some readers being put off by that. I didn’t find it bothersome.

I do have one gripe.

Every software process is based on assumptions about the cost of performing an activity versus its benefit. Plan-driven development methodologies typically emphasize spending resources on requirements because numerous studies have shown that making changes to fix errors late in the development process (or worst of all, after delivery) is orders of magnitude more expensive than fixing them in the requirements phase.

XP is also based on assumptions about the cost and benefit of the process and its constituent practices. As the author presents the reasoning supporting XP, he reveals these assumptions. For example, XP is predicated on the notion that changing software later in the life cycle is no longer prohibitively more expensive than changing it sooner. Mr. Beck writes “What if the cost of change didn’t rise exponentially over time, but rose much more slowly, eventually reaching an asymptote?” He goes on to acknowledge this this notion, “is the technical premise of XP,” (emphasis from the original text). Clearly, he believes that this shift in the cost curve has taken place.

However, the book itself offers nothing to support this view beyond anecdotal assertions that many design methodologies, languages, and tools are robust and mature. If this shift in the economics of development really has taken place, I would like to have seen a footnote or endnote supporting that conclusion. I read the annotated bibliography at the end of the book, and I couldn’t find such a reference. I’m not saying that the assertion is wrong, or right for that matter; I am saying that given its importance, a stronger case with better support should be made.

Even in later chapters, where the focus was on explaining the parts of the process, such as test driven development, I couldn’t quite shake the sense that there were too many leaps of faith necessary to get from “Could this work?” to “Does this work?” to “This does work,” to “This works as described.”

On the whole, I recommend this book. You may not agree with XP, but you’ll definitely come away with a clear understanding of what it is and the problems it addresses. If you’re looking to implement XP, you could probably get started from this book, but expect to need more information on the nuts and bolts of making it work day to day.