Book Reviews

The authors stress that feature-driven development, as they describe it, is intended for a very specific type of project. There's nothing new in the book, except the way the authors have combined tried-and-true techniques to handle very large business application development in a consistent and low-risk manner. The smallest headcount that could justify the overhead is about twenty, although it could scale up almost indefinitely. Palmer and Johnson describe their methodology as light but, on a scale of five (heavy) to one (agile), FDD rates about a four.

The second point is that the techniques used assume very heavy customer involvement and clearly understood business rules. For example, the original project that inspired the book was a banking system in Asia. The procedures wouldn't be well-suited to innovative product development in a competitive environment. This is no alternative to extreme programming.

Lastly, the methods used aim to get good results from inexperienced employees. Despite a reminder that highly-ranked programmers are better value than entry-level personnel, this type of project often relies on an army of tightly-controlled programmers, led by a few experienced team leaders. Although the authors differentiate the FDD organization from the old Chief Surgeon model, this is still basically just a variant on that theme.

There are also more than a few hints that the book is not intended solely, or even primarily, for US readers. We are abjured to speak in English and leaders are advised to use a soccer whistle to control meetings. As beautifully as the authors describe how to divide up a large project by feature (and it is beautifully clear and simple), some of the advice in handling personnel leads me to hesitate before recommending it without reservation to every potential reader, which is the criterion Amazon requires for a 5-star rating.

The three part approach to the book makes it easy for you to find the topics you need to get your job done. Part 2 defines each of the processes in detail. Chapter 5, which covers reporting/tracking progress gives a good feel for the control you have in producing project deliverables, and reporting on the true progress of the project. Realistic, acurate reporting.

I would recommend this book to anyone who is a slave to their process, or even those that are new to process. This one works!

This book is packed with good advice for developers and those involved in managing software development, and is clearly written by people with real world experience. The authors do a good job of explaining the issues in software development and how FDD helps address them.

The book is highly readable and should be accessible to those who currently have a limited understanding of formal software development processes. One of the themes carried through the book is an ongoing dialogue between the two authors and several other persons, including the project manager of a software project for a car dealership that is worked through in the book. At first I found this dialogue distracting, I guess because they were initially dealing with material I am already familiar with, but by the end of the book, I looked forward to these sections, and felt they gave the book an overall coherence.

FDD is most radical, in its approach to management (reporting), by dispensing with Gannt charts and estimates of task completeness (most people are aware of the 90% complete, 90% of the time, syndrome), replacing them with measuring features complete (as in 100% complete!) as a percentage of all features to be built. I am familiar with why Gannt charts and Microsoft Project style planning doesn't work for software projects, but the book would have benefited from a more detailed discussion of what will be the hardest part of FDD for many to accept. The book's only real fault is several digressions into software quality and online help, that it was hard to see the relevance of.

I recommend this book to people, including managers, who want to understand why we need software development processes and the issues involved in selecting one. The book, naturally enough, points out the issues with widely used processes such as RUP - too heavyweight, and XP - questionable scalability, and these criticisms are IMO largely valid. The book explains in a straightforward way, how FDD works and how it satisfies all the main requirements of a development process, especially scalability, manageability and getting the domain model (shape) right as early as possible, minimizing the need to refactor later.