While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.
Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.
George Dinwiddie is a software development consultant and coach with over thirty years of experience, and a speaker at this year’s CukeUp! in New York City.
We recently got the opportunity to ask George about the relationships of Behaviour Driven Development (BDD) to Test Driven Development (TDD), the importance of conversation in BDD and his upcoming session at CukeUp! 2014.
It seems that for many developers BDD is often seen as an alternative to TDD. Do you think that’s a correct assumption, or are BDD and TDD linked and dependent on each other?
These terms are not very precise, and have different interpretations. When Kent Beck invented TDD, he was doing it at the programmer level. Josh Kerievsky (I believe) coined the term Story Test Driven Development, for writing tests at the acceptance level for a user story. Others have called this Acceptance Test Driven Development. In some ways, BDD encompasses all of these, though the emphasis at the programmer level is often on the interactions between objects, rather than on the state of an object after an interaction.
Is BDD essential for effective teamwork and software creation or is there an alternative? Essentially, why should teams choose BDD?
Certainly people have been building effective teams and creating software long before BDD came along. BDD is a convenience, and a power tool to make development more effective. BDD describes the desired functionality with more precision than the typical requirements document. BDD promotes a discussion that’s equally accessible to the development team and the business asking for development. And BDD creates a safety net of regression tests that alerts us when we’ve violated a prior expectation.
You have 30 years of experience in software development and coaching – what have you learned in that time that you wish you knew from the beginning?
I wish I’d known that software (and hardware) development is not just a technical problem. It should have been obvious to me, since my undergraduate degree is in English with a Psychology minor, but I didn’t notice. I spent many years focusing all my efforts on the technical side of things, and losing years of opportunity honing my people skills. Both are important, but only very small projects get accomplished without collaborating with other people.
Back in April at CukeUp! in London, Elizabeth Keogh discussed some of the big things that have gone wrong over the past 10 years, specifically that BDD is not right for everyone, that a focus on automation can actually slow people down (too many scenarios, not enough conversations or conversations less about behaviour and more about how language should be phrased); she surmised that the conversations were the single biggest aspect of BDD. Would you agree with that conclusion?
I do believe that the conversations are the core aspect. Alistair Cockburn has said that the speed of software development is the speed of transferring an idea from one brain to another. Conversations with examples are perhaps the fastest way of doing this. I don’t exactly agree that BDD is not right for everyone (though they’re welcome to forgo it if they want). I do agree that the focus should be on the conversation, and the automation should support that. Not everything needs to be automated, and on a large project, you’ll never have time to automate every interesting scenario. One of the things to talk about are which scenarios seem worth running repeatedly and which ones are likely to detect problems that won’t easily show up elsewhere.
Your talk at the upcoming CukeUp! in NYC is focussed a lot on visualising scenarios in order to show clear understanding of what we or others should expect in the future. Can you give us a brief insight into this visualisation?
When we describe the behavior we expect our program to exhibit, we need to be specific enough that others understand our meaning. So often we, as people, are a bit vague in our conversation. If those we’re talking with share enough of our implicit assumptions and knowledge, they often understand what we mean. If not, they can ask. When we write this down, the reader is shifted in time from the writer, and it’s generally not possible to ask for clarification.
This leads us to expect more details. But which details? If we write every detail we can imagine, we obscure the intent, and the reader is not helped. Worse, we lead them astray, as they may think certain details are essential though we just mentioned them as an example. Writing scenarios is as much an art form as writing software. It takes work and attention to detail and correctness.
The aim of CukeUp! is not just for developers, but rather encompasses product owners, testers, business analysts and so on. How does your session address all of these stakeholders?
All of these stakeholders need to understand the scenarios, and ensure that their concerns are adequately covered in them. That’s why I recommend the “Three Amigos” approach to writing the scenarios. This approach writes them collaboratively with all the necessary points of view participating. With collaboration, they can spot when jargon from one stakeholder makes it unclear to others, or an example offered by one is too narrowly focused. Writing good scenarios is hard, and when it’s done from only one point of view, it usually misses the mark.
George will be speaking at this years’ CukeUp! conference Tue, 30th Sep – Wed, 1st Oct at DUMBO Loft, New York City.
He will be joined by a host of leading names from the world of Cucumber including Aslak Hellesøy (creator of Cucumber & co-founder of Cucumber Ltd.), Eric Evans, Mary Thorn, Paul Rayner and many more!
This two day conference will explore various aspects of BDD in this New York community event. CukeUp! is organised and curated in partnership with Cucumber Limited and also runs annually in London.