Extreme Programming Explored
(From the Back Cover)
You know what XP is, how to get it up and running, and how to plan projects using it. Now it's time to expand your use of Extreme Programming and learn the best practices of this popular discipline. In Extreme Programming Explored, you can read about best practices as learned from the concrete experience of successful XP developers. Author and programmer Bill Wake provides answers to practical questions about XP implementation. Using hands-on examples--including code samples written in the Java programming language--this book demonstrates the day-to-day mechanics of working on an XP team and shows well-defined methods for carrying out a successful XP project. The book is divided into three parts:
* Part 1, Programming--programming incrementally, test-first, and refactoring.
* Part 2, Team Practices--code ownership, integration, overtime, and pair programming; how XP approaches system architecture; and how a system metaphor shapes a common vision, a shared vocabulary, and the architecture.
* Part 3, Processes--how to write stories to plan a release; how to plan iterations; and the activities in a typical day for the customer, the programmer, and the manager of an XP project.
To demonstrate how an XP team uses frequent testing, you'll learn how to develop the core of a library search system by unit testing in small increments. To show how to make code ready for major design changes, the author teaches you how to refactor a Java program that generates a Web page. To see how a system metaphor influences the shape of a system, you'll learn about the effects of different metaphors on customer service and word processing applications. To show how customers and programmers participate in release planning, the book demonstrates writing and estimating stories, and shows how the customer plans a release.

Review By: Michael Yudanin
06/07/2004“Extreme Programming Explored” provides the user with the principles of Extreme Programming (XP), and explores the implementation of these principles. It provides insights into the recommended team practices and describes a day in the life of a customer, a programmer, and a manager. The book even addresses the office layout – a pretty important thing in XP. The book has plenty of examples, including whole pages of – understandable! – Java code.
The author leads the reader by the hand into the realms of Refactoring and Pair Programming; wonders together with the reader while beholding the might of the System Metaphor; writes the Stories and plays the Iteration game.
Refactoring is something that sounds very interesting, but in practice, when taken as XP prescribes, it may turn your code into a pile of spaghetti that will be very hard to handle.
Pair Programming may be an intriguing idea, but in practice it rarely works. The main reason is that people are different. For some, programming in pairs will work, for others it will not. The book describes very clearly and honestly possible problems with Pair Programming, but does not provide viable means to solve them.
A System Metaphor is a very short story – preferably one sentence – that explains the essence of the software system by example. In my experience, the metaphor is an excellent communication tool. It can put all stakeholders on the same page. Without it, it can be extremely hard to communicate the system’s purpose to the newcomers.
XP wipes out much of the traditional software engineering process. For example, Business Analysts are not in favor of direct communication with the customer. Now, try to imagine this communication when the customer’s language differs from the programmer’s in almost every dimension, and they have no translator.
The same holds for the requirements, which XP gathers through “stories.” Should the software process be programmer defined and programmer centered? To get a hint, consider a car design and manufacturing process that is not customer centered but rather automotive engineer centered…
If you want to understand how XP works, this book is for you. The author’s style is easy to read and the book is very well structured. Every chapter is followed by a list of references. The contents deliver the principles and the ideas, while the style – short paragraphs, numerous code examples, clear language – provides you with the soul of this approach. However, if you are looking for a software process that will bring more order and predictability to your software development shop – I would suggest you look elsewhere.