Review By: Richard J. Foster
12/22/2011For a software product, knowing what to build is vitally important to the project's success. As most methodologies stress, involving the customer (or someone actively representing the customer's interests) at an early stage in the process can reduce many risks and contribute to its timely completion as long as the communication between the customer and the development team is clear. In this book, UK-based consultant Gojko Adzic discusses the potential benefits of what he calls "specification by example" in minimizing communication problems.

The author asserts that by simplifying the specification to a series of representative examples in plain language, the user can more easily determine if the proposed solution accurately meets his objectives. Also, by using tools like Cucumber and SpecFlow the same plain-language specifications can be turned into automated acceptance tests, providing valuable feedback about the development progress. In addition, these "executable specifications" become a living document which can help future development—a benefit several contributors mentioned as a very welcome side effect of the other activities.

Something I particularly appreciated about this book was the use of real-life case studies and the emphasis on working within the appropriate context for a project. I was especially glad to see that the author includes alternate views, including some that he does not agree with, and provides commentary where applicable as to why activities may have been more beneficial in one situation than in others.

After having made several attempts to implement similar processes in the past, I tried using some of the ideas suggested by this book in a recent project. I was pleasantly surprised when our results very closely matched those described. In particular, by choosing different terminology (specifically, avoiding the term "test") when talking to the customer, I was able to confirm that our planned solution met our customer’s needs and also discover that making a simple change would allow the solution to support another area they hadn't initially considered. (According to Gojko, the word "test" is often understood by both customers and management to be "a supplemental, post-development activity I don't need to be directly involved with.")

If one of your objectives is to make sure you deliver what the customer really needs as quickly as possible, I strongly recommend reading this book. I have no doubt that, like me, you will learn something useful.