23 of 24 people found the following review helpful
on February 12, 2013
One one hand, the book is not deep, reflective and well argued enough to be a timeless classic. One the other hand, it lacks concrete examples, steps and instructions to be a timely and actionable cookbook. It hangs in a midair between realms of inspirational and practical, touching on both and delivering on none.
I was really looking forward to read this book after hearing an interview with the author on Devnology podcast. It pains me to admit that reading it was not a time well spent. How could the author call his approach "Specification by Example" and offer no end-to-end examples that could be studied, evaluated and replicated? Please comment with a page number(s) for such examples if you disagree, and I will be more than happy to admit my blindness.
21 of 24 people found the following review helpful
on June 24, 2011
Specification by Example is Gojko's third book on this subject. The first book, Fitness.net, was very technical and tool oriented. The second book, Bridging the Communication Gap, was a lot more coordination oriented. Now his third book, this one, he describes practices that teams he studied have used. From that perspective, this book is the follow-up of Bridging and might go a little fast if you are totally unfamiliar with the subject.
The book is divided in three parts. The first part is mainly introduction where Gojko describes the benefits and the key practices that will be described in this book. The second part is the actual description of the key practices and the third part are different case studies about different teams in different companies that have adopted specification by example.
The key practices that are introduced in part one and described in part 2 are:
- Deriving scope from goals
- Specifying collaboratively
- Illustrating using example
- Refining the specification
- Automating without changing the specification
- Validating frequently
- Evolving a documentation system
Deriving scope from goals discusses how customers main concert is not the software but solving a problem and developers shouldn't just expect to get the requirements from the customer but work together with them to help them to solve their problem in the best way. Specifying collaboratively covers how the customer and the teams will cooperatively define the specifications that the team will be implementing later. Illustrating using examples explains how these specifications can be described best by moving from abstract requirements to concrete examples. Refining the specification then takes the essence out of the requirements and describes them in the clearest possible way. After that, the specification can be automated without changing the specification and this chapter gives tips on how to do that. When the specifications are automated, you want to run them frequently which is described in the validate frequently chapter. Evolving a documentation system describes how the specifications become the documentation of what the system does. They stay in-sync with the system because they are continuously executed.
The third part described a couple of case studies of companies that implemented specification by example. I really loved these case studies and they were written very well.
I've read both of Gojko's earlier books and had high expectations for this book. I was not disappointed, it is an excellent follow-up and will be my standard book reference on Specification by Example (or A-TDD as it is also called). The book is not perfect though. As times I felt there was too much focus on documentation and too little on collaboration. Still, I'd rate this book five stars and recommend everyone in an Agile development team to read this and practice specification by example.
7 of 7 people found the following review helpful
on April 1, 2012
The book was well organized and timely. Most teams swerve to the extremes of the test automation path... this book advocates striking a pragmatic balance between spotty automated test coverage and a plethora of maintenance-magnet technical tests. SBE is shown as a treasure map.. and then each checkpoint is elaborated in a chapter. Lot of real world knowledge collated in this book...
* Don't let customers dictate solutions, instead challenge and extract scope/solutions via collaboration.
* Don't make test automation your end-goal. Move on to living documentation (although I have no clue on how to convince teams of the benefits).
* Keep specs readable by business users.
* Adapt your test suites to the current reality.. Fast feedback is key even for acceptance tests.
Nitpicks: Could have been a shorter book. I realized I don't like reading about case studies... maybe others would like it. I strafed over Part III. and at 50$ a pop, the price is a bit steep.
8 of 10 people found the following review helpful
on October 11, 2011
The concepts in this book, process patterns as Gojko describes them, seem quite straight forward and that's partly because they are, partly because they are very well described within and partly because they just make so much sense.
Its pages describe one of the most effective ways in which teams can build the right product and build that product right. Specification by Example harnesses some key attributes of agile frameworks such as Lean & XP in a mechanism that allows teams to get from business ideas to an implemented and evolving (self-documented) product with the minimum of fuss or waste.
What's more from the research undertaken with real teams in real companies, you the reader, can learn from the many other practitioners who have been using and honing these techniques in the field (that's a real field by the way, with grass and everything).
I think it's rare to get this amount of good practical advice from so many teams distilled into a single reference guide alongside the process.
A fantastic book which should be the accompaniment of every software team member!!!
5 of 6 people found the following review helpful
on August 21, 2011
When I started to read this book my impression was rather negative - looked rather as yet another piece of marketing blah-blah-blah. But when I reached the book core (chapters 2 - 10) I changed my mind completely. Yes, it's true that the book is oversaturated with success stories to which 7 of 16 chapters are devoted - but anyway it is one of the best books on a requirement collection and maintenance I ever saw.
It promotes a set of very important principles (listed in the chapter 2) that, strictly speaking, are not Specification-by-Example specific or even new - most of them are known from 70-s or early 80-s - but anyway are way too often overlooked or forgotten. To name a few of the (the most important as for me):
* Deriving Scope from Goals (a specification should answer not "how?" or even "what?", but "why?" and "what for?").
* Specification Refinement (specification should contain all necessary detail but nothing more and should be expressed on an appropriate level of abstraction).
* Specify Collaboratively - customers, business analyst, developers and testers should participate in the specification creation.
The above mentioned principles are a must for any successful software project - a project (save the most trivial one) seriously violating them can succeed by chance only.
If add to them two Specification-by-Example specific principles - Executable Specification (specification expressed as acceptance tests written not in the technical but in the business language) and Living Documentation (documentation consisting of or generated from automated acceptance tests) you may imagine which benefit Specification-by-Example may bring to your development.
The book considers a usability of Specification-by-Example in different scenarios and in differently organized teams (based on the real-life experience) and provide a well-grounded advices what to do - and what refrain from - based on the conditions in which your teams operates.
All this is on the bright side.
On the dark side are:
* Already mentioned oversaturation with success stories - yes they play as important role as background and illustrations, but may safely be shortened 2-fold at least, as for me.
* The book describes advantages but is almost silent about inherent dangers and drawbacks of the proposed approach. To be honest, it avoids them not completely; there are a few words on some of them here and there - but not enough as for me. And the main dangers - fragmented, incoherent and non-uniform solution and an exponential growth of complexity in the behavioral tests - are not even mentioned explicitly (yes, there are talks about "an appropriate level of abstraction" and "key examples" - but it is not enough).
* The book overestimates a "less rework" effect provided by the approach - as with any specification developed and implemented piecewise there are high chances to miss on early development stages a requirement critical for internal structure of the system inevitably causing a massive rework of the system core. Moreover one of the success stories contains the following passage "From the first day of development, the Talia team used Specification by Example and built up a living documentation system. After a year of development, they had to rewrite the core of the virtual agent engine from scratch." There is no explanation why this "rework from scratch" becomes necessary - but there are good chances that it was for the reasons explained above.
Smaller things that I really like:
* "Building the product right and building the right product are two very different things. We need to do both to succeed."
* "Instead of a technical feature specification, we should ask for a high-level example how a feature would be useful."
* "I generally don't agree with the categorization of requirements into functional and non-functional groups, but that is probably a topic for another book." - BTW, I am likely wrong qualifying this point of view (which I myself advocate from early 90-s) as a "smaller thing".
* "Scripts are not specifications" - perfectly said, scripts inevitably specify "how" not "what for".
And smaller things which I rather dislike:
* Maintenance costs of the automated acceptance are underestimated - along with possible bugs in fixtures.
* "It never happens" syndrome is not dealt with (I mean business customers that tend to specify a happy-path only and for any border cases cut discussion short claiming "it never happens" - needless to say that the question is not "if" but "when" it happens).
* There is a statement in the Introduction/ This book has no source code and does not explain any tools section: "Once you get the communication and collaboration right, a tool might help to make it go smoother." - which is only partially true, as without an appropriate tool it is virtually impossible to obtain an executable specification and a living documentation, 2 major benefits of the Specification-by-Example approach.
* Quite ambiguous/imprecise statements:
o Chapter 2, Evolving a documentation system section states about a living documentation "It is as reliable as the code, but much easier to read and understand." -almost true, as this documentation is almost as reliable as code (subject to misinterpretations/bugs in fixtures, parts of/paths through of the code not covered with automated acceptance tests etc.).
Despite all small (and not so small) problems mentioned above the book is really great!
4 of 5 people found the following review helpful
on November 3, 2011
So many organizations that do 'Agile' don't understand that there is a process by which teams need to work in order to understand what they are building. Having led many organizations through this effort I had developed many of the types of processes that are presented in this book, but Gojko has provided guidance around all the many types of projects that teams face while trying to be Agile on top of it.
One of the biggest questions I have always received is how do you scale a process for specifying your work via Examples so that small projects can obtain the same benefits and this is covered very well in the book, it has given me many new ideas about how to work within smaller project/team structures.
If you are just starting Agile, read this book, your teams will benefit from the discipline of Specification by Example. If you are already Agile this book will help you get better, improve your velocity, lower defects identified and generally make the process of moving fast less stressful.
Quality isn't a word is a process and this book will help you build the right process for your organization.
1 of 1 people found the following review helpful
on October 26, 2011
The heart of the practice Specification by Example is the unification of specifications and tests. This unification guides development teams to avoid several of the common anti-patterns in software development; like testing bolted on at the end, and documentation getting out of sync with the implemented functionality.
The book Specification by Example is the result of drawing experiences from how a number of actual project teams work with the practice Specification by Example. This makes the book particularly valuable, since its advice in not solely based on theories or opinions on how develop software, but it distills experiences of what has actually worked in different situations and in different domains.
The ideas of the practice Specification by Example have been in use for some time now, under different names like Acceptance Test-Driven Development, Agile Acceptance Testing and Behavior-Driven Development. The author chooses in my mind a sensible terminology for the practice itself and its different parts, or process patterns to use the authors term.
The book has two main parts, the description of the process patterns of Specification by Example, and a set of case studies of project that uses Specification by Example. In addition the book contains an introduction to the practice of Specification by Example and guidelines on how to introduce the practice in organizations.
These process patterns of Specification by Examples are described together with tips about "does" and "don'ts". The case studies part of the book contains six case studies covering a diverse set of domains.
As a software developer that was "test infected" 10 years ago, a think that the practice Specification by Example, essential for successful and efficient software development. I think this book is the best book on the market today, for learning and adopting the practice Specification by Example.
2 of 2 people found the following review helpful
on March 1, 2014
Great book. I think you can only appreciate the contents once you have got into other practices like Continuous Integration, TDD and unit testing. This is a high level view of different teams and the challenges they have faced when implementing specification by example.
5 of 7 people found the following review helpful
on January 30, 2014
This book is not much more than a collection of case studies. I found nothing in the book that can be used to apply "Specification by Example" in a real-world project. There are no detailed examples of code or documents, just generalities and stories about the benefits of the author's approach. I feel that both money spent on buying the book, and time spent on reading it were simply wasted.
2 of 3 people found the following review helpful
on October 4, 2011
This is the third book I read from Gojko Adzic in this area and the one with absolutely highest value. For me, as a developer, thinker, scrum master and in the bottom a person who cares a lot about the people I work with and our customers - this is a book I have been waiting for. It does not solve all problems, but give the reader tools for working with the root cause of many problems - short and long term communication. To build the right product in the right way we learn how to build living documentation meanwhile keeping it testable.
In this book the author does not claim any of the techniques to be his own, but to be the result of a set of studies in real life projects. This speaks very much to my emotional side, but if followed up by some more metrics (both hard and soft) it could have gotten even further into my scientific mind.
The book was for me filled with ah-ha moments and I would like so say it is a feel-good book. It gives hope for people that might have struck out in agile-like projects that face many of the problems that teams featured in the book solved with help from Specification By Example.
The author is successful in explaining many of the topics in language that I think appeal to both developers, testers and project sponsors. This is done very much by not involving certain tools or contexts and by not excluding other adjacent methods.
Gojko is very humble in tone, but sometimes not so humble in "matter". I like this!
My main question and maybe critique after finishing the book :
How to get it working in the organization as whole? I realize this is not unique for SBE and that the book actually gives quite some attention of this in chapter 4, but this is still what I would have liked to bring with me from the book. For now, this will be for each and one to find what will work in her own context.
Bottom line : the book is a must read!