Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes. Each feature is captured as a “story”, which defines the scope of the feature along with its acceptance criteria. This article introduces the BDD approach to defining and identifying stories and their acceptance criteria.
I’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period—typically 2-4 weeks—to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.
At the beginning of this year I wrote a feature article for Better Software magazine, which was published as “Behavior Modification” back in March.
The article is now available on my site. It gives an overview of behaviour-driven development, from its origins as a coaching aid for TDD through to its current form as a proven, comprehensive development approach.
I had a problem. While using and teaching agile practices like test-driven development (TDD) on projects in different environments, I kept coming across the same confusion and misunderstandings. Programmers wanted to know where to start, what to test and what not to test, how much to test in one go, what to call their tests, and how to understand why a test fails.
The deeper I got into TDD, the more I felt that my own journey had been less of a wax-on, wax-off process of gradual mastery than a series of blind alleys. I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.
I was going to write about the various ways that people learn, and then my colleague Jeremy Stell-Smith wrote an excellent article describing one of my favourite learning models, so go and read that and I’ll see you back here shortly. Jeremy also alludes to Shu-Ha-Ri, another learning model based on repeating “cycles” of learning, found in Japanese martial arts (I haven’t linked to a single definition because there are a few subtly different ones around).
When Darwin’s “On the Origin of Species” was published, evolution was already a well-established idea. Darwin’s insight was that evolution—through the process of natural selection—led to the introduction and extinction of entire species. This of course upset the established church, and to this day there are still religious groups who reject the idea, in the face of overwhelming scientific evidence.
The early twentieth century saw the rise of “neo-Darwinism”, which finally provided a mechanism for natural selection. It wasn’t happening at the level of creatures but at the microscopic level of genes. Natural selection is simply the playing out of a long-running stastistical game based on shuffling genes, and more disturbingly the creatures themselves (and ourselves) are just a very sophisticated form of temporary accomodation for those genes!
Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).
Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.
This question came up at the recent Expo-C conference, when presenter Michael Stal talked about designing services to be “as simple as possible but no simpler”. Kent Beck advises us to do “the simplest thing that could possibly work”, but this is often mistaken for “the first thing I could possibly think of” or even “the only thing I know” (also known as the Golden Hammer antipattern).
We picked up the topic as an open space session later that day. I took the position that you should only ever focus on the specific case in hand, and then only generalize if you meet another similar case. Erik Meijer, the reknowned language guru and thoroughly nice guy, took the opposing stance that you should abstract the general solution and then implement it locally. He pointed out that this was an approach with centuries of mathematical tradition behind it and is a fundamental tenet of modern functional programming1. This developed into a good-natured but heated stand-off. I just couldn’t see the value of building a fancy general solution on the client’s money, when there was lots more important work to do and limited time. He couldn’t understand why you wouldn’t take the effort to make something as flexible as possible for the end user, especially if you were designing something like a programmers’ toolset or language. On the scale of specific to general—or concrete to abstract—we were at opposite ends, with a seemingly intractable chasm between us. He was simply wrong, and so, of course, was I.
Adopting agile practices is a step-change for many senior managers and business sponsors. Don’t underestimate the importance of getting them onside early in an engagement, and making it “safe” for them to explore and adopt agile practices.
I am lucky enough to have been invited to present at Expo-C, a software architecture conference based in Carlskrona, Sweden. The dates are 16th to 19th May 2006.
At the risk of dropping names, last year’s conference included sessions by the likes of Rod ‘Spring’ Johnson, Rickard Oberg and Jimmy Nilsson, and this year’s line-up includes, well, take a look for yourself.
In a moment of insanity, the organisers have given me a whole day to play with, the Tuesday, so I’ll be running a number of sessions with an agile theme, rounded off with a retrospective. I’m going to see how little PowerPoint I can get away with. I’m aiming for Zero Slides.
From the session summary
The Ruby language has taken the development world by storm. Its combination of clean, object-oriented syntax (everything is an object) coupled with Perl-like platform independence and inline text processing power make it a useful tool both for writing small utilities and as a rapid prototyping language. The popular web framework, Ruby-on-Rails, allows for easy development of highly-functional web applications.
This session will explore these aspects of Ruby, namely for utilities, prototyping and web development. We will also discuss issues such as scalability and deployment.??
I was lucky enough to attend the Software Architecture Workshop in Cortina recently. It was a three day workshop based around the idea of Open Spaces, which involves handing the asylum keys to the inmates and seeing what happens.
I convened a session called “What’s so hard about Event-Driven Programming?” to explore the experiences of the other delegates in designing, implementing and testing asynchronous, event- or message-driven systems. I took the position that actually it was all very straightforward as long as you followed a few basic principles. Another delegate, Mats Helander, took the opposing view that asynchronous, event-based systems could develop scary emergent behaviour that would lead to a world of hurt.
Automated builds have become a cornerstone of agile development. Every time a developer checks in a change, a tool like Cruise Control checks out all the sources, builds everything, runs all the unit tests and reports back with immediate feedback. This cycle has become known as Continuous Integration, due to the seminal paper by Martin Fowler and Matt Foemmel, but this is something of a misnomer. It is better described as Continuous Build. (Their use of “integration” was about integrating all the bits of software that the various programmers in a team would traditionally be working on in isolation from one another, only to bring together and spend days or weeks getting to work. Practices such as pairing and automated builds have all but eliminated this form of integration hell, at least on agile projects.)
So, it’s taken me two years to finally get round to writing down what behaviour-driven development is all about, but I’m pleased with the result. The article has just been published in the March edition of Better Software as “Behavior ((I didn’t quite get away with the UK spelling)) Modification”.
I started talking about BDD as an evolution of TDD at the back end of 2003, and played with the idea of a BDD framework, in the form of JBehave, during 2004. I made some noise about it at the Agile Developers’ Conference in June 2004, and then at the end of the year everything went kind of quiet. That’ll teach me to have a day job.
Charles Simonyi introduced himself at a recent workshop with the words: “I was at Xerox PARC in the 70s, Microsoft in the 80s, and working on intentional software in the 90s”. He wasn’t showing off, he was just there. He pioneered WYSIWYG, created Microsoft Word, Excel and Access (as a data visualization tool), championed OO and invented metaprogramming.
What this tells me is that when Charles Simonyi thinks he is on to something, it’s probably worth listening. (Ok, I’ll forgive him szHungarian notation.) For the last 15 years, Charles has been on to intentional programming.