Seb Rose and Gáspár Nagy are the authors of The BDD Books. Cucumber Community Manager Tracey S. Rosenberg spoke to them about their books, the writing process, and what comes next.

Tracey: How did you decide, “Let us write books together about BDD?” Where did this all come from? What’s the origin story?

Seb: At some point, maybe five years ago, maybe longer, Gáspár was thinking about a SpecFlow book and got in touch with Cucumber. The rest of the team said, “Seb, you could work with Gáspár on the SpecFlow book!” And I said, “That'd be wonderful.”

Gáspár: It was at least six years ago, definitely. When we were less busy ⁠–⁠ or we thought we were less busy! ⁠–⁠ we started to shape the form of the SpecFlow book. We wanted to make a new structure emphasizing all the goodness experienced by the BDD community regarding the BDD concept, and of course also how SpecFlow works. Discovery and formulation are not tool-specific, so we knew they shouldn’t go into a SpecFlow book. Also, discovery and formulation are separate activities. Because of this, we decided to write a separate book for each BDD practice.

Seb: We also realized that one big book was going to take one hell of a long time. So if we wrote a small book, we’d be able to get it done more quickly.

Tracey: Did you collaborate on all the different parts of every book, or did one of you say, you put an outline together and I'll do the full write-up?

Seb: My time was in short supply when we were doing the first book, so I said, Gáspár, you write it and I’ll review it. We reversed that for the second book. Gáspár will write the third book, which is about SpecFlow. We have a fourth planned as well ⁠–⁠ in the style of 97 Things Every Architect Should Know, we’ll seek contributions from the community and edit them into a book of styles/patterns.

Tracey: And how does your process work?

Gáspár: Almost every week for the last few years, we’ve spent at least an hour together and discussed what was happening. Then we try to make progress on the book, so it’s good to have allocated time to work together. We realized it didn’t make sense to write the book together, so that's why we use this “one writes, the other reviews” scheme. But we also need to discuss these things. Even more importantly, we need the inspiration to move on. Book writing is not easily motivational, because it takes a long time.

Tracey: Oh yes it does.

Gáspár: And even after that, you don't really see your readers, or maybe you see a few of them. So one of the important bits was that during these sessions, we were asking each other, how much have you finished? If you do that a couple of times, you feel that now, this week, I should really do something.

Seb: There's definitely guilt. You go to a meeting on a Friday and you think, “I haven't done what I said I was going to do last Friday.” But that’s life.

Gáspár: We're all equal from this perspective.

Seb: In terms of logistics, Gáspár does all the technical work of putting the books together and getting them onto Kindle, after I’ve turned all the text into something close to English. I do the marketing.

Gáspár: For the cover design, I put a draft together, and we were thinking about replacing it with something more professional, but then we decided it wasn’t necessary. For the second book, we used the same concept as the first ⁠–⁠ basically, we have geometrical colours in the background, and an antique which shows the beauty of engineering. On the first one we had a compass, and then for this one, we have a very nice pen. I don't know what will happen with the third book. I'll figure it out.

Seb: I think we can get one of those, you know, where they used to make solar systems that you wound up and turned round. That's a few years off, though!

Tracey: How has the reception been? Not just raw sales, but comments, or praise, or “why didn't you do this?”

Gáspár: For the second book, it was easier, maybe because we had a little bit of history, or maybe we were handling the review process better. Generally the review comments were positive, and in general, we got nice feedback from many people. I think our praise quote list is two pages long! It was clear these people were really checking out the book, not just writing a few sentences because we asked them. We’ve also had good feedback from the readers.

Seb: When we wrote Discovery, we pinged Daniel Terhorst-North and asked him to either review the book or give us feedback. His response was, “Sure, I’ll help you promote it on Twitter.” So it's like, okay, that's nice. This time we asked him for a praise quote, a sentence or two, and he wrote back and sent us a foreword! So if Dan feels like it's worth him writing a foreword, when he hasn't even been asked for one, that's good feedback. I was well happy with that.

Tracey: High praise indeed. So what makes this book worth reading, if you’re trying to improve your BDD skills?

Gáspár: We didn't want a book which says, “This is the way you should do it, and if you don't do it that way, you’re doing it wrong.” That kind of approach is far from how Seb and I work. But it’s not easy to show the real trade-offs that teams have to choose between.

In both books, we have a team ⁠–⁠ they’re working on an imaginary product called Where is my Pizza? ⁠–⁠ and this team is trying to solve concrete problems. They have options, they debate, and sometimes they say, well, we can't even make a decision about that.

The imaginary conversations crystallised our understanding of the doubts that teams experience. Sometimes we include extra material to cover some areas in more detail. If we can imagine a real team having these sorts of discussions, it probably makes sense to the readers, or at least gets a little bit closer to the kind of discussions teams have.

It was funny, because over the six years we were writing these books, the characters began living their own lives. Sometimes I imagine what Dave would say, or what Tracey requires ⁠–⁠ we have a Tracey as well, by the way.

Tracey: Fantastic!

Gáspár: Maybe at some point we’ll do a dramatization of the book.

Seb: There’s an audiobook of Discovery.

Gáspár: It’s also worth reading because formulation is a very practical topic. Everyone who deals with BDD needs to sit down and write the “given, when, then” sentences. I remember my own feelings, ten or eleven years ago, where we were not prepared for that ⁠–⁠ we just came together in a meeting and wrote the first scenario. We started with "given” and then said, “uh oh, wait a second, ah, how should this go?” I think that's a situation many people face. Obviously the discovery part is important, but to make the connection to discovery, formulation is the immediate need. People have to understand how to write down and create these scenarios. Hopefully the book gives enough guidance for that. Also, it shows that when you put more of the discovery practice into your process, it becomes even easier.

Seb: There's been quite a lot of development in the BDD field over the time that we’ve been writing this book. This idea of discovery, formulation, and automation comes out of writing these books. It was inspired by the work of Liz Keogh, but Gáspár came up with the term “formulation”, and I suggested we divide the SpecFlow book into three books, aligned with discovery, formulation, and automation. That fed into the diagram Matt Wynne eventually created for the BDD documentation on the cucumber.io site.

Discovery, Formulation, and Automation

Seb: These books don't simply document what we've done, or what other people have done ⁠–⁠ they’re part of the evolution of BDD. Gáspár came up with the term “formulation” around six years ago, and no one had used it in this way before. In fact, when we called the great and the good of the BDD world together, there was a lot of pushback against the term. People wanted to call it specification or whatever. We said, fine, everyone do what they want, but we carried on calling it formulation, and that's the word that stuck. So yeah, go us! Go Gáspár!

Gáspár: To be precise, I didn’t come up with the word. I don't know who deserves credit for it. I did bring it into this community, certainly. I think it’s important that we have names for things, and that some names are unique. English words, obviously any kind of words, can be used in multiple different forms, so there is no one single meaning of a word. You could use specification, or you could use documentation ⁠–⁠ there are many words that would be fitting ⁠–⁠ but when you use a word that’s a little bit special, that reduces the confusion. If I say “specification” or “documentation,” those words are overused. “Formulation” is special, and in the BDD context, everyone knows what we’re talking about.

In this interview:

Gáspár Nagy

Seb Rose

Learn more about the authors