Dahlia Bock

JAOO: Dan North – Behavior Driven Development, Writing Software That Matters

I attended my first ever software-related conference this week, and it was, of all things, for free as a volunteer! Thanks to Zaynab who introduced me to Lisa Cumes at the one of the Geek Girl Dinners in Sydney.

Behold JAOO, and my first session: a tutorial with Dan North on Behavior Driven Development (BDD).

When we say BDD, a lot of developers tend to think about tools like JBehave or RSpec or Cucumber that encourage the behavior-driven-writing-of-code, writing tests with keywords like it should or acceptance criteria with the given-when-then template. But BDD is about changing the way we think about writing software, about how we deliver software and about what constitutes software that matters and software that has no value.

What are the steps or processes we go through to deliver software?

1. Planning
2. Analysis
3. Design
4. Code
5. Test
6. Deploy

Look familiar? Ideally a software project would undergo a rigorous planning phase to drive out all the goals, then we will run through them with a fine-toothed-analysis-comb to drill out the requirements, and then we hand those requirements over to be typed out into functional design specifications, then further into code, then we dedicate 3 months of intensive testing and finally plop that application into production and let it run oh-so-smoothly!

If you've been on any software project, you would know that that is a myth. Projects never run that smoothly, and the best we can do is shorten the feedback cycles as much as we can so we can fix a problem as soon as it arises, integrate often so things don't blow up in our faces when we try to piece two things together, expect change to happen so we write code that can handle it, etc.

Effort-based metrics are also a myth. Dan gives us this metaphor to explain why:

If you know a full tank of gas allows your car to go 300 miles, if you've driven for a while and the meter shows you have half a tank, then you know you have driven for about 150 miles. But if leave the car with the full tank of gas turned on in your driveway, come back the next day and see that it has half a tank of gas left, how far as the car gone?

So how can we measure faster/better delivery?

1. Deliver features rather than modules
2. Adapt to feedback
3. Flatten the cost of change
4. Only focus on high value features
5. Prioritize often, change often

If we are on a 1-week project, when do we know if we are going to be late? Definitely towards the end of the week, or as soon as the week is over. So if we shorten the feedback cycles, we'll be able to gauge how we are doing much easier.

So how do we get there using BDD?

Getting our words right. We need to identify our core domain but it's only useful if it helps us identify the problems and solve them. Often we make a mistake of thinking that the object model and domain model are the same thing, but they are not. Our domain is what makes us different in our industry, it is what sets us apart. Dan gave the example of UPS, the shipping company. Fedex and DHL had a very large market share in the shipping industry but UPS pioneered the online tracking system, allowing customers to know where their parcel is anywhere in the world.

Enough up-front thinking. Identify the need. Our outcomes/goals can be broken down into feature sets and/or themes, and further broken down into features/stories and then to individual cards on the wall. We also have to be careful to not focus too hard on the cards on the wall as a one-dimensional line, but keep in mind the big picture of the project/system as a whole and how they relate to the customer's needs. Fabio has a diagram that visually explains this.

Focus on the value. When we have stories, they can take scenarios, and scenarios can take steps: given-when-then. The event of the story, the when criteria, has to be done from the point of view of the stakeholder so that they get the most value when the story is done.

Agree on 'Done'. Define acceptance criteria as scenarios. Given the following story:

As an Anesthetist, I want to view the Patient's surgical history, So that I can choose the most suitable gas

One of the acceptance criteria can be:

Scenario: existing patient with history
Given we have a patient on file
And the patient has had previous surgery
When I request the Patient's history
Then i should see all the previous treatments

There will be other scenarios for when the patient hasn't had any previous treatments, or when the history for that patient doesn't exist, etc. We automate those scenarios and they become acceptance tests, which in turn become regression tests.

Introducing BDD or any new way of thinking or doing things is a big change. We want lasting change that involves influencing values and beliefs. We should look to making those changes with small increments. Find quick wins instead of trying to change everything all at once.

*Note: My favorite part of Dan's tutorial was looking for doing small increments and finding quick wins when introducing change. He previously talked about transitional architecture where we should view architecture as a changeable entity, if it doesn't work, we take steps to make it better. Josh Graham also mentioned this point in his JAOO talk, that architecture should be continuously evolving.