The simplest Cucumber project ever

Extreme YAGNI: How BDD nails your prototyping stage

Sometimes people don’t see the value in the BDD process. They contend that the BDD ceremonies are a waste of time, and get in the way of delivering real features to customers. Others cannot see how to apply BDD to their project, as no-one knowns exactly what the project will look like yet. As they’re only in the prototyping stage, by the time a feature file is written and made executable, it’s already out of date.

I don’t agree with this. If our process is set up right, we can prototype using just as effectively and retain the collaboration benefits that BDD gives us.

You Ain’t Gonna Need It

One of the biggest wins that Test-driven Development (TDD) gives us is the principle of YAGNI - “You Ain’t Gonna Need It”. It’s very tempting when writing code to go off on a tangent and produce a beautiful structured work of art that has zero practical use. TDD stops us doing this by forcing us only to write code that a test requires. Even some experts who don’t practice or encourage TDD often espouse the power of writing the calling code first in order to achieve much the same effect.

BDD gives us the same YAGNI win: but at a level higher than TDD. With the BDD cycle we’re adding thin slices of customer observable behaviour to our systems. If we can only write the code thats directly used by the business, then in theory we should be cutting down on wasteful development time.

However, there’s a snag here. if we’re prototyping, we don’t know whether this feature will make it into the final product. We still need to give feedback to our product team, so we need to build something. If the feature is complex, it might take a while to build it, and the feature might never get used. Why bother going through the process of specifying the feature using BDD and Cucumber features?

Happily, we can take YAGNI a level further to help us out.

Extreme YAGNI

Often in TDD, and especially when teaching it, I will encourage people to take shortcuts that might seem silly in their production code. For example, when writing a simple supermarket checkout class in Javascript, we might start with a test like this:

    var checkout = new Checkout();
    expect(checkout.total()).toEqual(0);

Our test defines our supermarket checkout to have a total of zero on creation. One simple way to make this work would be to define the following class:

    var Checkout = function() {
      this.total = function() {
        return 0;
      };
    }

You might think that’s cheating, and many people define a member variable for total, set it to 0 in the constructor, and miss this step out entirely. There is however an important principle at stake here. The code we have does exactly what the test requires it too. We may not need a local variable to store total at all.

Here’s the secret: we can practice this “extreme YAGNI” at the level of our features, too. If there’s a quick way to make our feature files work, then there’s nothing to stop us taking as many shortcuts as we can to get things working quickly.

For example, if we’re testing the user interface of our system via Cucumber features, one fast way to ensure things are working is to hard code the values in the user interface and not implement the back end behaviour too early. Why not make key pages static in your application, or hard code a few cases so your business gets the rough idea?

Again, you might think that’s cheating, but your features pass, so you’ve delivered what’s been asked for. You’ve spent the time thrashing out the story in a 3 amigos meeting, so you gain the benefits of deliberately discovering your software. You’re giving your colleagues real insight to guide the next set of stories, rather than vague guessing up front. Our UX and design colleagues now have important feedback through a working deployed system very quickly, and quick feedback through working software is a core component of the agile manifesto.

By putting off implementing the whole feature until later, we can use BDD to help us navigate the “chaotic” Cynefin space rather than just the “complicated” space. This in theory makes BDD twice as useful to our business.

Fast, fluid BDD

This all assumes that we have a fast, fluid BDD process, with close collaboration built in. If it takes a week to coordinate everyone for the next feature file, then the temptation is to have a long meeting and go through too many features, without a chance to pause, prototype, deliver and learn from working software. Maybe it’s time to re-organise those desks and sit all the members of your team together, or clean up your remote working practices, or block out time each day for 3 amigo sessions. You’ll be suprised how much small changes speed your team up.

Why BDD works solo, and why that matters for everyone

“The monotony and solitude of a quiet life stimulates the creative mind.”

– Albert Einstein

It’s possible to play chess and many other games completely solo, without anyone else to play against.

Incredibly, our minds are able to take on the role of both players in a competitive match. Our brains allow us to place ourselves in the opposing player’s shoes. Even more impressively, we are able to hide certain information from our own decision making process – such as what we’re planning to do next turn. We can analyse this incomplete set of information and play a move based solely on that, even if it’s sub-optimal.

BDD can be done solo

Using Behaviour-driven Development (BDD) on our own is much the same as playing a game against ourselves.

Instead of playing the opposing role, we take on the role of the stakeholder. We put ourselves in the shoes of the person paying for or commissioning the project. Because the BDD practice of writing gherkin-style features forces us to think in plain English, we jettison the role of programmer for a moment, and drift in the non-technical solution thought-space.

Why is this important? It’s a valuable exercise for a couple of reasons:

• We gain a fresh perspective on what we are doing. By taking our heads out of the code and putting ourselves into the role of the stakeholder, we are able to see the wood for the trees and get perspective on the code we’re writing right now. It might be interesting code to write, but does it matter?

• We gain a fresh perspective on the stresses of others. Every developer should take the opportunity to be a stakeholder once in a while. It’s very helpful to see what life it like on the other side of the estimation table. If all the members on a team are able empathise with the constraints and pressures our colleagues from different disciplines have, our team will run much more smoothly.

BDD solo is why BDD matters in the first place

Sometimes we confuse the concepts behind BDD with the tools used to practice BDD, like 3 amigo meetings, story breakdown and Cucumber.

BDD isn’t about the tools we use, it’s about the communication in the team. It’s about having the right conversations at the right times, hammering things out together, airing and refining thoughts and ideas, beating out ambiguity and forging common goals. This is why it matters.

If it was just about the tools, BDD would have been lost in the noise years ago, and BDD solo would be an expensive overhead. Why add another layer of tool complexity if it’s just us?

However, because BDD is about the concepts, not the tools, BDD works just fine solo: the process of deliberately stepping outside our developer role and thinking through our project from a product perspective gains us insight and understanding. This works no matter what tools, languages, frameworks or practices we may prefer.

When we’re solo, we dispense with a lot of the tools we don’t need. We don’t need to schedule a 3 amigo meeting with ourselves, for example. We’re left with a very pure form of BDD, set free from the needed constraints of multi-person teams.

Then we can begin to understand which of the common practices of BDD are only there to work around problems and can be discarded as needed, and which are truly foundational.

Try it out

Try using BDD on a personal project. Play the product owner, and write some Gherkin-style features. Pretend you can’t code. Really think about your problem without thinking about exactly how you’re going to solve it.

Whilst doing this, reflect on what practices you really need, and which you don’t. Which tools are less useful on your own? Which are more useful?

If you feel we’re just wasting time, I’d challenge us to think about what that’s telling us about our own ‘standard’ agile practice. How much of it is truly making us more agile, and how much of it is simply getting in the way?

How to layer context into your features using Real Narrative

Take a look at this Cucumber feature and see what you think:

Feature: Power allocation on ship

  Blaster fire rippled across the rear of Charles's fighter. One of his engines immediately caught fire as the bullets tore through the outer casing, and the core reactor started to overheat.

  "Damn," thought Charles. He flung his ship hard left with one hand on the flight stick, using the other to knock out power to the damaged engine and route it to front shields. The large pirate cruiser loomed into view over his left shoulder. Slamming full power to engines and shields, he drove his ship straight towards the danger. Enemy bolts flashed off his shields like a mini light storm, but they held firm.

  Soon he was within range. With power to short range missiles and rear shields, he fired all three remaining missiles at the last possible moment, right at the belly of the enemy ship. Charles overshot the cruiser, pulling his ship around in a wide arc, keeping an eye out for their next move.

  Scenario: ...
    Given ...
    When ...

Preambles don’t have to be boring

This preamble uses real fictional narrative to make its point.

The whole point of the preamble is to provide this context for your feature. This allows the business and the customer to get the development of the feature right. Why shouldn’t we include some actual fiction to give us a flavour of the feature that’s required?

This might seem easier with a space shooter game, but narrative on any project, even one that is more business focused, will help to get across a sense of how the feature should feel.

If we employ our reader’s imaginations, it’ll help them connect to the intangible reasons for the feature that we can’t quite fit in a concise agile story description.

Proper context drives implementation

The narrative above gives me plenty of context to write stories such as these:

Scenario: Allocating full power to a single component
  When Charles allocates power to engines
  Then engines should be given full power
  And other systems should be dropped to minimal power

Scenario: Knocking out power to a component
  When Charlies knocks out power to a component
  Then the component should no longer receive any power
  And the component cannot be used
  And the reactor stops overheating

It also raises plenty of questions. What happens if I push full power to two seperate systems? How should that feel to the player? Should that cause overheating? Should it even be possible? The narrative has driven a conversation with more depth and richness that I might not have had otherwise.

Behaviour-driven development is for everyone

Who says that BDD is just for business web apps? It can work for games, too, any any other kind of software project. We’ve shown that in any domain where technical and non-technical people have to communicate about a software project, the core tenets of BDD are useful.

Whether it’s software for a space shooter or a sugar factory, real people are always involved. There’s always a translation process from great concepts to carefully crafted code. We should make that process as painless as possible.

Let’s choose to be interesting

The things we often write down in our stories are often the least interesting part of the conversation. Sometimes, in a drive to be pithy, we miss the point. How about we take a chance and include some actual narrative in our feature preambles and our story writing?

How are you leveraging the power of preambles to add context to your features?

Make Cucumber features more readable with this one weird trick

“Sorry I’ve written such a long letter; I didn’t have time to write a short one.”

– Blaise Pascal

If you’ve got an issue with your customers not reading your feature files, then try this: it’ll help ensure their eyes stop glazing over.

As I travel around coaching teams doing BDD, a common problem I see with Gherkin features is that they are nigh on unreadable except by the people that wrote them… and even then, the writers often have trouble explaining what they mean.

This often happens when non-technical stakeholders have little to no involvement in writing features, leaving technical people free to be as obscure as they like. It’s easy to write an obscure feature: it takes a lot less effort to ramble and choose the first words that come to mind, rather than crafting carefully considered prose. The pain comes later: an obscure feature is imprecise, error-prone and unmaintainable, as the effort required to understand it will stop others from maintaining it.

How I help people simplify their features

When asked to review the language of a preamble, I read the feature out loud, and then ask the writer of the feature what it means.

A deep breath often follows. “Ok, this is the one where…” The writer will explain the feature clearly and concisely using completely different words to what is actually written in the feature. They use great contextual information that’s missing from the written preamble, and work to ensure I really understand what’s going on.

Once I’ve got a good response that I can understand, I ask the writer to replace the preamble with exactly what they just said.

It’s never exactly what they said (natural language is different to spoken language, after all) but it’s always better than what they had before.

Sometimes, when asked what the feature means, the writer will give a short hesitant explanation, and then proceed to read out the preamble again. My response is normally: “yes, but what does it mean?” Occasionally I have to ask five or six times until I get a considered, clear response.

This also works for scenarios, scenario descriptions, tag names, etc.

Why this works

Sometimes it’s easy for us to get so wrapped up in the detail of the features that we’re writing that we’re unable to see the wood for the trees. Our features read much more like computer code than they do plain natural language.

Features are communication tools first and foremost, and leveraging different ways of communicating while writing them will help to ensure they’re as carefully considered as possible.

(This works for natural prose, too. if you write a blog, documentation or even just emails to colleagues, taking a moment to read your text out loud will tell you in an instant whether it makes sense.)

A challenge

Pick a feature on your project, and read it out loud. If it makes no sense, explain what the feature does to a colleague and ask them to write it down for you. If it reads awkwardly and could be improved, take ten minutes to do so. Your future readers will thank you for it.

BDD Kickstart is dead. Long live...

We are coming up to the one year anniversary of the first public BDD Kickstart, and we’ve got some news…

Matt and I have enjoyed running BDD Kickstart over the last year or so. We’ve had hundreds of people go through the course in all, with courses run for the public and privately in-house.

Over the year we’ve grown a team of real expert practitioners who also happen to be fantastic at teaching and mentoring. Seb, Rob, Julien and Steve have been partnering with us to help us run many more courses than we could have done on our own. With Suzan publicising and marketing the courses, we have built up some great momentum: enough to expand our course lineup.

BDD Kickstart’s fundamental philosophy has always been to put you in a room with experts. With the addition of new partners, we’re growing the range of subjects we can offer at that very high quality level. We can offer courses in more than just BDD. So we needed a new name.

Introducing…

Quality matters to us enormously, so we’re growing slowly. We’re focusing on running our existing Continuous Delivery course, and we’re already running in-house Ruby courses. We’re writing a “Hexagonal” course to teach pure OO design principles for modern web applications.

We’d like your feedback please!

We’re actively seeking feedback to help guide us as we grow and expand. Your emails are always welcome, but we’d especially like to speak to you on the phone if:

• You have been on a course with us and you have some feedback or a testimonial
• You’ve been thinking about coming along but haven’t done so yet for specific reasons (location, can’t spare the time, financial, etc)
• You have an idea of a subject you’d like to learn from us that we don’t offer yet

Send us an email with your phone number or Skype handle and we’ll set up a call.

What’s next

We have two public courses available at the moment: we’re teaching our popular BDD Kickstart course in London in December and our Continuous Delivery course in Paris in March. If you’re interested in either of these courses, you can sign up for London now, or email us to express your interest in the Paris course.

It’s an exciting time for Kickstart Academy: we look forward to seeing you at one of our workshops soon!