Review By: Bill Tuccio
05/11/2004This book details the steps involved to implement the eXtreme Programming (XP) methodology. The XP process is a series of steps that puts all project participants in tune with the pulse of the project and its deadlines. These steps include requirements broken into short user stories; the customer on-site with the programmers to adapt to changes and answer questions; programmers writing units tests before the code; continuous integration of code into builds; minimal coding to achieve functionality; pair programming; time estimates based on experience with the project; and lightweight metrics that help steer the project to completion.

Authors Ron Jeffries, Ann Anderson, and Chet Hendrickson pick up where the first XP book (eXtreme Programming Explained, by Kent Beck) left off. They describe every element of XP, leaving nothing to doubt about how an XP project should be run. Central to XP is the acknowledgement that as a product develops, the requirements are seen more clearly by both customer and programmers and that this growing experience should be used to the benefit of the project by continuous refactoring to improve code quality, adjustment of what features go in what release, adjustment of time estimates, and adjustment of metrics.

The book details the importance of unit testing every piece of code in the system and designing modules in such a way that such code is conducive to definitive unit tests. Every release requires that all unit tests are run to a 100 percent pass rate. Unit tests are distinguished from acceptance tests, which gauge-test the product against business requirements. Also emphasized is the importance of adapting to change by “steering” iterative releases. Steering involves customer’s and programmer’s reacting to experience on the project and modifying functionality to stay on the agreed track.

The authors write in a light-hearted and easy-to-understand voice that brings out the XP mood: cooperation, courage, no-nonsense metrics, and object orientated programming. XP says that each programming unit is driven by a user story and that the programming unit will be no longer than two or three weeks of work. So, too, do the authors write their book by making no chapter longer than a couple of pages that can be absorbed in fifteen or twenty minutes. When a topic needs expanding, they simply drill into it in the next chapter.

XP is defined as a discipline that is driven by and requires strong skills of both customer and programmer. The programmers need to know how to communicate, refactor, adapt to change, and listen. Customers need to know what they want in their product, how to compromise on features, how to adapt to change, and how to listen. XP demands a close working relationship with the customer so that programmers can work off minimal initial stories and fill in the details as the details emerge while coding. XP demands of all parties acceptance of a key paradigm: What they are building cannot be fully known at the outset; it will develop as the mass of the product develops.

If you’re going to implement XP, this is the book to read. It will help define the roles of all parties in the XP project, set up the work environment to prepare for the on-site customer and pair programming and ad hoc design meetings, and give all team members a common expectation of how to proceed. The authors take the time to add what they call “bonus chapters” that define some additional real-life XP experiences, including coding and steering exercises. They also start every chapter with some great cartoons that aptly introduce the content.

The book particularly helped me understand the importance and methods to achieve unit testing of 100 percent of the code on 100 percent of the releases and also how to code unit tests before coding the functionality. As a developer, that concept is something that will apply to everything I write, whether XP or otherwise.

Last, if you are trying to decide to buy this book or “eXtreme Programming eXplained” by Kent Beck, consider that “eXplained” defines the methodology and is useful for the high-level manager trying to understand if XP may work for their organization, while “Installed” is more appropriate for participants in an XP project, including customers, managers, and programmers.

To learn more about eXtreme, search StickyMinds.com on “eXtreme.”