Extreme Programming (XP) is a new programming methodology that's getting fairly heavy notice these days. As Kent Beck is one of its main proponents, and seems to have coined the term, it seems reasonable to treat this book as the defining standard of the field. XP is the application of a group of practices to software development projects:
What XP amounts to is abandoning the traditional "waterfall model" of development entirely in favor of what has often been called "cowboy coding". Beck argues that it's no longer vastly more expensive to fix problems in production than in planning, and as a result, it's not necessary to plan. Instead, let your programmers program, trust them to solve problems as they come up, and plan and ship frequently so that you get feedback from the customer on a regular basis.
It's a seductive vision, particularly for the developer who's tired of working in an organization that enforces design standards, documentation, and conformance to a predefined architecture. I've no doubt that this has worked for Beck and his cohorts on a variety of projects.
That said, I'm none too impressed with this book. While XP may work for specific teams composed of motivated programmers, I don't see it as being as revolutionary or as useful as its promoters would have you believe.
There's no attempt in this book at all to measure the improvements of XP, beyond some vague guesses that XP developers are twice as productive as ones using more traditional methodologies. Beck talks about the importance of measuring improvements in your own development projects, but he doesn't share any hard numbers from his own projects. That pushes this book more towards polemic than programming. I also don't see the slightest understanding that Back has ever heard of the Hawthorne Effect, let alone considered that it might apply to his own work. He insists several places that the first thing to do is rearrange the furniture. Guess what? It was established decades ago that rearranging workplaces almost always leads to an improvement in productivity, regardless of what the rearrangement is.
Beck does devote a chapter to the sorts of projects that aren't appropriate for XP, but this chapter is at the very end, rather than where I think it belongs, up front. And his discussion of when not to use XP is couched entirely in terms of what projects aren't good for it, rather than which developers shouldn't be using it. This makes it appear that XP is a near-universal solution. I suspect rather that it's a very particular solution, that works on some projects with some teams.
There's also no notion that the practices might not work perfectly. Take the notion of continuous testing, in particular. The idea is that you should test all of your code on your machine, not integrate it to the main project before it passes your unit tests, and then only keep it if the integrated code passes the entire test suite for the product. This is not an especially new idea. Microsoft, for example, uses this testing pattern on all of its products. Guess what? It doesn't scale well to large programs, where running the test suite takes a long time. On products such as Office it's not unusual to find that the daily build is broken because of interactions between multiple code check-ins. Unit and integration testing helps, but Beck appears to assume that if the unit tests work the integration tests will always work, and that this can always be quickly enough checked to not interfere with the XP rhythm.
Finally, on a note not pertinent to the methodology, Addison-Wesley has chosen to overprice this book substantially. It's $29.95 for 166 pages of text (plus end matter...personally, I don't really care that the author thinks The Princess Bride and The Structure of Scientific Revolutions belong in his bibliography). Worse, the text itself is substantially padded, with many ideas being repeated two or three times and long stretches of philosophy that are of interest if you want to know where XP ideas came from but don't have much to do with implementing them. The meat of the entire book could have been boiled down to a single essay without losing much -- but then, of course, it couldn't have been published as a book.
Overall impression: 0. If you're already familiar with the field of software engineering, and you find this one in a library, it's worth skimming. If you want to know about running a development effort, there are much better books to start with.