Book Review: Specification By Example

Disclosure: Manning Publications is a sponsor of the Chicago Sencha User Group, and they provide free copies of of their books as giveaways for our monthly meetings. I have not been paid for this review, although I did receive this book for free.

Specification By Example Over the past year or so I’ve probably read a dozen technical books. Technical books are very curious in that some are really good and others are simply terrible – there’s not many that fall in-between, and that’s often because these books involve specific topics and rely on code-heavy content.

Specification By Example is the first technical book I have read in a long time that has no code. It’s an interesting dichotomy… but one that I think works really well in this case. In fact, that’s ultimately the point of the book: creating project specifications before you start writing code.

What I Liked

I have been a unit testing fanatic for some time, and I really appreciate how much time the author spends talking about automating “tests”… though he is very clear in that “specification by example” is not the same as “test driven development”.

According to the author, automated tests (not necessarily “unit” tests) should describe the system and be human readable – creating living documentation! Overly technical tests (and code) force developers to reverse engineer the business logic – which defeats the purpose, and should therefore be avoided.

In fact, that’s probably the thing I liked most about the book: the idea that “business rules” should be clearly documented and approved before code development begins. Teams should collaborate in order to achieve this goal, and the resulting “specifications” should be revisited often.

In short, mistakes are harder to make when managers, developers and testers all understand the business requirements… and these “requirements” should not be “suggested implementations”.

Some quotes from the book include:

“When teams focused only on test automation, the didn’t get better collaboration”

“Unless the only way to get confidence out of automated specifications for a feature is to run them end-to-end through the UI, don’t do it.”

“Check only UI functionality with UI specifications”.

The author even goes the extra mile, explaining how to get the business leaders on board with the Specification By Example process. There is lots of good advice, and plenty of real-world examples to illustrate each concept.

What I Didn’t Like

There really wasn’t anything to dislike about the book. I will say the book could be a bit dry at times, but as that’s par-for-the-course with other technical books I can’t really complain.

Chapter 2 introduces the concept of “living documentation” – and maybe it’s because I’m too far into the development world, but I found that I didn’t understand precisely what the author was getting at until I saw figure 2.2 (a screenshot) on page 22. Had the author been more clear (or direct) sooner, I would not have been forced to reread the previous pages to re-enforce my new-found understanding.

Final Thoughts

If you’re a technical manager or senior developer (or in a similar position) you should probably read Specification By Example.

It certainly changed the way I will be approaching future projects, and I will continue to recommend this book for a long time.


With nearly 20 years of software engineering and operations experience, Arthur Kay offers an extraordinary set of leadership skills and technical expertise to develop meaningful products and high-performing teams. He has worked with Fortune 500 companies, VC-funded startups and companies across a wide variety of industries to build cutting-edge software solutions.

Arthur is a successful entrepreneur, technology professional, and mentor. He is a full-time family man, part-time consultant and spare-time musician. He graduated from Loyola University Chicago and currently lives in greater Chicago-land.

2 comments for “Book Review: Specification By Example

  1. April 7, 2012 at 5:07 am

    Thanks for the review. I’ve been reading this book for quite awhile and if anyone isn’t familiar with the topic, it’s a must read. However, I’m not so sure it deserves such high praise as Amazon’s visitors give it. “Test Driven” – by Lasse Koskela in 2008 covered this topic quite well (he called it Acceptance TDD). “Specification by Example” has way too many anecdotes at the beginning; Part 1 (first 62 pages) leaves you with a feeling of “Ok, I’m sold, just tell me how to do it already!”. This topic is not new, despite the book’s high ratings. Frameworks such as Fit/Fitnesse have been around for several years, and what this book describes is what they had been invented for. Not to say there’s no new information here, but a lot of what is said in the book can be gleaned by using Fitnesse plus a few tips on having your users work with you to create the “executable specifications”. Actually Adzic did one thing, he gave us a vocabulary for it; hopefully it’ll catch on, because before this there was a LOT of terms to describe this process which caused a lot of confusion.

    • Arthur Kay
      April 9, 2012 at 2:20 pm

      SunKing2 – good points.

      I haven’t read “Test Driven”, but maybe I’ll check it out based on your recommendation.

      You’re also right in that this isn’t a new topic… but I do think many software developers are oblivious to the idea. Developers are often uninvolved in the “requirement” process, or at least until much later in those discussions. I feel that developers in particular would benefit from reading this book for that reason alone.

      I will agree that I thought the author should have “just told me how to do it already” early in the book… the use of so many anecdotes probably contributed to some of the dryness I mentioned. That being said, Adzic’s clear vocabulary is certainly re-enforced by the examples.

Leave a Reply

Your email address will not be published. Required fields are marked *