Join us in London on April 2nd-3rd for our public BDD Kickstart class taking place just before CukenFest. This two-day class led by Jon Jagger explores all the technical and non-technical skills needed to apply BDD in your organisation to deliver less buggy software. Learn more

This blog post is the transcript of a conversation between our very own Seb Rose and InfoQ's Shane Hastie. The pair cover how Seb sees three central practices of BDD, his thoughts on including testers in code reviews, but he starts with why he thinks "passion" isn't a trait he looks for in colleagues.

Shane Hastie: Good day, folks! This is Shane Hastie for the InfoQ Engineering Culture Podcast. I’m at the Agile 2018 Conference and privileged to sit down with Seb Rose. Seb, you are one of the founders of Cucumber Limited and you describe yourself as the dispassionate developer. Tell us a little bit more.

Seb Rose: I started seeing the word ‘passionate’ kick off in job adverts, maybe 10-15 years ago. This is a conversation without pictures, so you can’t see either of our great beards, but I’ve been around for a while and I just didn’t understand why ‘passionate’ was being used. I feel that people that get passionate are often people that are less rational. I know that that might offend some folks, but I don’t want passion in the workplace. What I want is people to be considerate, I want people to be diligent, I want people to be involved, but the word ‘passionate’ doesn’t imply any of those things to me. So, a number of years ago, I did a pecha kucha at an XP Conference called ‘Are you passionate?’ where I suggested that passion wasn’t what we really were looking for and since then, various people picked up on it and I’ve much amplified it by my Twitter description where I say I am dispassionate developer.

Shane Hastie: You’re also known for your work on Behaviour-Driven Development. You want to tell us a little about what’s happening there?

Seb Rose: I came across FIT and FitNesse during my tenure at IBM. I’ve spent most of my life as a freelancer, but I’ve done a couple of stints with large corporations, IBM being one of them and Amazon being another. It’s true to say that FIT and FitNesse really wasn’t picked by my colleagues at IBM, but I got really interested in it. Subsequent to that, I worked for an insurance company and by that time, I was beginning to tinker with Cucumber. In those days, Cucumber was still just a Ruby project. I wasn’t working in Ruby and when Aslak released the Cucumber for the Java version – Cucumber JVM – I just thought, “Wow, this is amazing. Let me have a go at this,” and actually, within the context of the insurance company that I was working at, we had an absolute perfect-fit project, where we working with actuaries and business people.

The whole project was around repricing insurance. There was very little technical stuff going on, but there was a change of data, there was a change of business rules, so the discussion, the Cucumber business-readable specification was just an amazing tool. As a side effect of that, we then also decreased the testing cycle from about a week and a half to around an hour and that was a game change for them. In the repricing situation they were in, they were fairly sure that the whole market was going to be moving on a daily basis and they wanted to be very flexible in repricing. Obviously, a three-week approval cycle for repricing is not going to give you very much flexibility, whereas a one-hour testing cycle was just what they wanted.

That really sold me on the power of Gherkin to Cucumber to describe technical, deep business rules in a business-readable language and from there, I’ve engaged with Aslak in online communication. His partner in crime, Matt Wynne, actually also lives in Scotland – on the other side of Scotland from me, but Scotland’s not that big a country. So, we met up after a conference in Edinburgh. I started working with Matt, I drank the Kool-Aid, he taught me everything that he was prepared to teach me about BDD and how Cucumber helps roll out the implementation of BDD and the rest is history.

Matt, Aslak and Julien Biezemans founded Cucumber Limited in 2013 and invited Steve Tooke and myself to become co-owners a couple of years later. I’ve been running the training arm of Cucumber Limited for the past three years. I’ve developed training material using experiential techniques which I’ve learnt from Gerry Weinberg and Sharon Bowman. I do a lot of conference speaking. Basically, I guess I am a proselytizer for BDD as a collaboration tool. I joined Matt and Aslak and the rest of the team in trying to dissuade people from using Cucumber purely as a test automation tool.

Shane Hastie: Tell us a bit more about using Cucumber as a collaboration tool.

Seb Rose: Behaviour-driven development has been historically hard to describe. There is a nice quote that Matt Wynne put into the first Cucumber book, which is a sentence which describes Cucumber as a combination of conversation, concrete examples and automated tests, but in many environments, I find that it’s not immediately understandable to the people that read it. Dan North, who created BDD, has also tried to come up with some definitions. They’re also quite hard to parse and don’t immediately talk to the people who really need a definition.

Based on discussions with Liz Keogh and while Gaspar Nagy and I were writing a book called ‘Discovery’, we created a small pictographic which shows BDD as being made up of three distinct practices which we’ve called Discovery, Formulation and Automation. Cucumber only kicks in at the Automation space. However, what we show in the pictographic is that you have to start with Discovery.

Discovery is the practice that you need to start with and that’s about communication between the business and the delivery team. The delivery team will be made up of predominantly developers and testers, but not excluding designers, UX, security, performance, whatever it might be. During the Discovery phase, we have face-to-face communication between the business stakeholders and the delivery team. That conversation is targeted at making sure that everyone understands what’s being asked and why it’s being asked. It gives us a chance to use concrete examples to make sure that those requirements, those business rules that are being asked to be implemented are defined unambiguously because our experience is that business rules, acceptance criteria, requirements are rife with ambiguities and potential for misinterpretation. This is the Discovery phase. At the end of this Discovery phase, we expect to have the business rules clarified by one or more concrete examples to make sure that they can’t be misinterpreted.

Then with tools such as FIT and FitNesse and Cucumber, you would take those concrete examples and convert them into a format that is still precise, still unambiguous, but is readable by non-technical members of the team – not just testers, not just developers, but also business people, customers etc. That format within the Cucumber ecosystem is called ‘Gherkin’ and people will be familiar with the given-when-then keywords of Gherkin. Gherkin is by no means the only way of doing it. There are many other tools and formats that allow you to do this, but the critical thing is that it must be concrete, unambiguous examples documented in business language so that business people can give you feedback on them. That’s the Formulation phase.

Then, the third practice is Automation where the concrete examples are effectively wired up into the system that you’re building. In the recommended approaches, we would suggest that you go through the discovery practice on a story, take those concrete examples and formulate them as Gherkin, then automate those concrete examples before anyone starts writing the code to implement those features. What you’ve got is Behaviour-Driven Development.

In Discovery you’ve discussed the behaviour, in Formulation you have captured it as business-readable documentation and in Automation you are now driving the development of the system by a failing specification. Some people might want to call them ‘acceptance tests’. I’m easy on terminology here. Those are the three practices that form BDD. Cucumber comes in at the end where it reads the Gherkin and wires it up to the system that you’re building.

Shane Hastie: And that then leads nicely into the technical approaches of TDD.

Seb Rose: Exactly.

Shane Hastie: We’re doing TDD at the middle level.

Seb Rose: Yes, and one of the questions that we often get asked is, “Does BDD replace TDD?” It’s worth stating for the record in absolute terms that no. BDD supplements TDD. You go from a BDD-failing specification to a much more detailed, low-level programmer facing tests that will drive out the tiny increments in behaviour that you would expect from a TDD approach.

Shane Hastie: Thank you for that! Another thing that you’re known for is your work on the Cyber-Dojo. Tell us a bit about that.

Seb Rose: I am part of the Cyber-Dojo organisation. It’s an open-source project that was founded and created by a man called Jon Jagger, a very close colleague and friend of mine in the UK, and he created it to help him with his training of teams to practice programming and Test-Driven Development specifically. I encourage anyone listening who is in any way interested in the development of software to go and take a look at cyber-dojo.org. What it does is it provides dozens of online development environments that you can access with no install and no cost, which means that if you want to practice with people writing Swift or C++ or Java, press a button and you’re in a very lightweight IDE.

It also ships with dozens of Katas that you can practice and it has some wonderful training tools which provide you multiple avatars or multiple groups working on the same problem at the same time and some brilliant tools that allow you to compare different group approaches to solving the same problem. It’s a wonderful tool. It’s free to use for individuals. We do ask for businesses that use it internally for launching or training their teams to pay a small license fee. 100% of the license fees go to buying Raspberry Pis for schools in developing countries. It’s a win-win all the way down. It’s here to help your teams practice and the money generated goes towards helping people in more disadvantages places get into the IT space.

On including testers in code reviews: "We’re not asking people who are not experienced in a particular programming language to try and work out whether the semicolon is in the right place...What we’re trying to do is ensure that the code itself is written in a way that anyone can read and understand the flow in the structure."

Shane Hastie: Easy enough to find! At the conference, you’ve given a couple of talks. The one I would like to explore initially is the certification. What’s the state of certification and what are your thoughts there?

Seb Rose: The talk I gave was on the "IEEE’s future of Agile track" and I wanted to explore the domain of certification because it’s become a huge industry within the Agile space. I had a particular interest because in Cucumber, as the training manager, I have recently being trying to enlarge the number of people that can deliver our training material without decreasing its value or exposing us to reputational risk. Certification is one of those things that I was interested in.

At the same time, a lot of the people that I respect within the Agile community believe that the certification that is available in the Agile space is not great, that a lot of it is paying money for a certificate that you then have to revalidate. It’s just a treadmill of making money out of people. The talk that I gave was just a 30-minute talk and I looked at the four different certifications that I reviewed while trying to work out how to pitch a Cucumber formal approval process. They included the PVG Certificate that you have to get if you want to work with children. That stands for ‘Protecting Vulnerable Groups’. I looked at Chainsaw Certification because although it may seem that software and chainsaws are quite dissimilar, you can do a lot of damage with software and a bad code or a bad Scrum master could really chop up a team like you could chop up a tree. I looked at a couple of other certifications, too.

The talk was basically looking at the proprieties of these different certifications or approval schemes. What do they guarantee? How do they help the people doing the certification get value? How do they help the people obtaining the certification get value? How do they help the people who use the certification as some sort of signal or differentiator build that trust in those people that hold certificates? A fair amount to get through in half an hour and I’m not sure I did it justice, but as part of the process within Cucumber, we came up with something that we call ‘the Cucumber-Approved Trainer scheme’ and that word, ‘approved’, was put in possibly a little bit thoughtlessly. We actually did it because we liked the acronym that it built. We now have a body of CATs and we’re trying to herd the cats.

The Cucumber-Approved Trainer Program is quite onerous because one of the things that we found in the certification that we trusted was that it wasn’t a one or two-day course with a multiple-choice question at the end of it. It was something that had a prolonged interaction between the provider of the certification and the person gaining certification. Our program requires people first off to go through a phone or online interview to try and make sure that they’ve got the right background, right motivation, that we can communicate with them and that they can articulate things in a way that’s understandable. Then, we go through three interactions – training and engagement – which we stole entirely, lock, stock and barrel, from the Chainsaw Certification, and they call it “See it, do it, nail it”.

In the ‘See it’ phase, you are a participant in a training class which means that you get to understand the interactions, you get to see how a qualified and experienced trainer works with the cohort. Then, in ‘Do it’, you participate in delivering it, but in conjunction with another qualified trainer and in the third, ‘Nail it’, you deliver that training material, being observed. In all parts of this process, the people you’re working with gather feedback, interact with you to try and ensure that we pick up on any weaknesses, that you can focus on areas that you want to improve in.

There’s no guarantee that you’ll ever make it through the ‘See it, Do it, Nail it’. We may feel and you may feel that you need to go through the ‘Nail it’ a couple of times before you’re happy. At that point, you get the badge, you go on the website as being an approved trainer, you can deliver our training material and contribute to the evolution of it and join the community of CATS and get information from there.

Shane Hastie: Another talk that you gave encouraged the inclusion of testers in code reviews. Surely, that’s just logical today?!

Seb Rose: I would have thought it was logical, but you don’t see it very often. Despite the fact that Agile is in mainstream – certainly has crossed the chasm – I still see a proliferation of organisations where cross-functional team is a name only. The testers still report to different management structures, they might sit with the team, but they still operate on different columns of the Kanban board and it still gets chopped over the edge. We see stories that are so large that testers may not have a huge number of things to work with during much of the iteration and on the night before the end of the iteration, all the stories get delivered and so, then there’s a panic.

There are a lot of dysfunctions in many organisations that are adopting Agile and I very rarely see testers interacting with the code at any level. There may be communication and discussion between the test and the development people, but actually, going in and participating in code review… I hardly ever see it. We should qualify this by the fact that I work as a trainer and coach for Cucumber Limited and typically, we don’t get invited into places where everything’s peachy. I probably have a kind of biased or distorted view of the industry, but having spoken to a lot of people here today – and there were 50 or 60 people in my talk the day before yesterday – I don’t think that my viewpoint if wildly off from the norm of what people experience.

Shane Hastie: For somebody who wants to encourage that sort of, “Let’s move to a more cross-functional team, let’s engage our testers…” One of the things I’ve heard from a few testers is, “I don’t even want to read the code. I don’t understand that stuff.” How do we bridge those gaps?

Seb Rose: The great thing about trying to get testers involved in code reviews is not that they’re reviewing the code. We’re not asking people who are not experienced in a particular programming language to try and work out whether the semicolon is in the right place or whether this is an efficient algorithm. What we’re trying to do is ensure that the code itself is written in a way that anyone can read and understand the flow in the structure. That should include having method and variable names that echo concepts from the domain.

This is something that, for instance, Bob Martin has talked about a lot in his books about clean code. It’s about doing literate programming, literate in the sense that we are reflecting domain concepts all the way through the lifecycle of software, from specification through to delivery. If you write your programmer tests with names that specify what the behaviour is that they are asserting or verifying, if you write your method names with terms from the business domain that describe what functionality or behaviour they’re offering, if you give variable names that talk about the domain objects that are being passed around, now you can involve technical-literate, business-literate testers in that space and they can then begin to think about, “Is this an approach that I can see matching the requirements that I have heard the business people ask for?” This then encourages discussion.

It also helps because the testers can now see what programmer tests are being written and actually may take a view of where is there a gap. Are there some tests that the programmers have missed? Are there errors where there’s clearly risk that I should do more exploration in? It gives everybody information. It gives the programmers information about, “I’ll be writing in a literate way that is going to be understandable by the next programmer team that has to pick up this product.” It gives the testers information about, “What testing have the developers already considered?” This allows lots of different areas of cross-skilling, up-skilling and risk-management around, “Where should we focus our exploratory efforts?”

Shane Hastie: Thanks very much for taking the time to talk to us! If people want to reach out and carry on the conversation, where do they find you?

Seb Rose: Twitter is always a good place. My name is Seb Rose, my Twitter handle is @sebrose, my LinkedIn handle is Seb Rose and I'm seb@cucumber.io.

Shane Hastie: Thank you very much!

Seb Rose: Thank you!

Join us in London on April 2nd-3rd for our public BDD Kickstart class with Jon Jagger. This is a two-day class which explores all the technical and non-technical skills needed to apply BDD in your organisation to build less buggy software.