Review By: Tilmann Bruckhaus, Ph.D.
07/16/2003This book explains how agile software development and extreme programming can be applied to the development of commercial software. The driving beliefs behind the book are that no amount of planning can prevent requirements from changing, and that you should start coding right away rather than completing requirements documents, architectures, and designs in the absence of code. Obviously, these beliefs go against commonly held notions which call for at least one iteration of careful planning, architecture, and design before diving into the code.

The agile/extreme approach becomes credible when you consider that it does not argue for neglecting to plan, architect, and design. The process does not begin with detailed requirements. Instead, the book describes a process of capturing the essence of customer needs. You select a subset of needs to address in an initial iteration of coding. Coding is done by writing test cases first, and then writing code that allows the test cases to pass. Then you go back to the customer and show what you have done. You then flag misunderstandings, select the next subset of needs to address, and iterate through the next loop.

A key concept in this process is that the members of the development team are paired for each coding task. Code should not be written alone. This helps ensure that code can be maintained more easily. Programmer pairs are mixed-and-matched in each development iteration to allow for even more eyes to see each section of code as it evolves.

The book seems to implicitly assume that your software development project is of medium size and geographically local, as opposed to largescale and internationally distributed. For example, it is argued in the book that the customer needs should be captured on index cards in terms of bullet points that allow the project team to remember conversations with the customer.

This approach will only work if you have a local, stable development team of moderate size. It's a different story if you have a large, distributed team with noticeable turnover. Conceivably, agile programming and extreme programming can be adjusted to allow for large, distributed teams with turnover; however, the book does not address those issues.

The book is written for software developers, software development managers, and business analysts. The book describes the process of agile development and extreme programming, design principles, and provides four case studies. Agile development is explained in terms of its underlying philosophy, and how planning, testing, and code improvement (refactoring) are accomplished.

A key strength of the book is in its rich examples and case studies. This is clearly not a book that someone has dreamed up in the ivory tower. The author has used the techniques he advocates, and he has diligently documented and illustrated these techniques in great detail.

One of the most useful contributions from this book is the very readable overview of six common design principles. It is clear that the description of the principles is founded in deep experience with applying them in practice. The design principles are illustrated with the help of examples of their application to realistic problems, code listings, and clear design diagrams.

Some value-adds are provided in the form of an introduction to the UML notation, an easy-reading satire of two companies (one uses agile development, the other doesn't), and a reprint of a 1992 letter-to-the-editor from Jack Reeves to The C++ Journal. Readers unfamiliar with UML can use the UML introduction section to understand the design diagrams used throughout the book.

In summary, this is a rich book with credible tools, advice, and examples. The book is well-written and clearly structured. It is invaluable for anyone interested in agile development and extreme programming.