Extreme Programming Explained: Embrace Change (2nd Edition)

Kent Beck (2004)
Review date: January, 2009

The book comes in two parts. First there is a part containing the theory behind Extreme Programming expressed in terms of values, principles, and practices. These, in turn, are broken down further to concrete sections: Values are about communication, courage, and respect. Principles about economics, improvement, and quality. Practices are divided into primary and secondary, and contain things like sitting together, slack, continuous integration, test-first programming, and single code base. The chapters above contain many more sections, and I've only picked out a dew to give a general summary.

After the core theory comes a chapter about different roles in an XP team, and some chapters that wouldn't fit into the core. Here we find testing, scope management, and scaling of XP teams.

"Philosophy of XP" is the title of the second section, which is more free-form. Here author sells his concept by relating it to taylorism and the Toyota model. Some emphasis is put on choosing an experienced coach for teams that want to adapt XP. The last chapters are even more speculative and provide a soft landing discussing things like the community part of XP.


Reviewing this book is quite difficult, since it's easy to get hung up one of the concepts and start a discussion in favor or against it. Personally I'm not a fan of pair programming. In my experience it only works if both programmers have the same skill and style, or as a technique for introducing new people.

You see? I didn't even start before I was trapped! So, what I'm going to do is to try to review this book without arguing against the principles... too much. Here we go!

For a starter, you should read this one whether you're an agile and XP zealot, or if you find the practices outlined here ineffective and ridiculous. The book is one of the classics, and even if you disagree with the author, it still contains a lot of knowledge and experience. Having said that, let's look a the some highlights.

Not surprisingly, the first 20 pages look very similar to those in "Test Driven Development By Example". Again emphasis lies of courage, respect, and feedback, which we recognize very well, if we have read the former. These are in fact some of XP's values. Before hitting the actual values, the author presents his view of the relation between values and practices, by using principles as a bridge. I didn't find that very convincing, mostly because of the names of the principles. The thought is good, but the distinctions between the criteria for being a practice or a principle didn't always appear crystal clear to me.

Anyway, speaking of principles, there was one I found particularly appealing: mutual benefit. While discussing this, the author acknowledges the difficult situation of optimizing the work for yourself, or making a time/effort sacrifice that will benefit the project in the long run. As I find the first approach being very common in our industry, I welcome every word written about this.

Quite close to the former insight we find another stating that people tend to think too much about software instead of just developing it. This isn't a problem I recognize, quite the opposite in fact, but I understand how it may develop.

"Sacrificing quality is not effective as means of control. Quality is not a control variable. Projects don't go faster by accepting lower quality.". These are the first lines of the quality section (it's a principle by the way). I seldom quote texts, and never use a bolder font to support it. This quote speaks best for itself...

Then there are some things I don't agree with, like cramming people into open space areas, and pair programming, but let's leave it at that. However, you must browse to page 43, where there's a picture of a middle-aged man leaning over a woman in a way that makes her uncomfortable. The purpose of the picture is to demonstrate the need for space when pair programming. The whole discussion is highly amusing. Read it.

Among the practices we find things like planning work for one week, continuous integration and test-first development. These have made their way into other agile methodologies, and it's nice to see where they come from.

Many other interesting topics are discussed in the book, but I don't want to spoil them all. However, there's one more I'd like to take up for discussion: towards the end, the author attacks the software construction metaphor, advocated by people like Steve McConnell (for the sake of those who haven't read any of McConnell's books it can be said that he has made impressive contributions to the industry through his various books, that describe pretty much the opposite of XP). The argument itself is quite valid, and I'll recommend some googling and news groups to see how it was received when published. I'm actually not going to spoil it by publishing it here.

Like many evangelizing books, this book suffers from "I have said all I have to say in 100 pages, and need to fill the rest with dubious quality material" syndrome. The last 50 pages contain some gems, but are not really that exciting.

All in all, I recommend reading it. The book touches on virtually everything in the field of software development, and it will either give you a confirmation of what you believe, or make you sharpen your arguments.

Who should read this book

Many people in the industry are affected indirectly by XP by all agile methodologies that contain more or less of what constitutes the core of XP. Therefore both programmers and managers should invest the small amount of time needed to read this one. This book is after all the origin of a widely accepted methodology.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.