Monday, July 20, 2009

Behavior Driven Development

The RSpec Book: Behaviour Driven Development with Rspec, Cucumber, and FriendsAt QCON 2008, Dan North gave a talk about BDD. Dan start by stating that projects fail because the products come in too late, cost too much, do the wrong thing, are unstable in production and crash every day, break the rules, or the code is impossible to work with.

Next Dan compares the bottom up and top down approached to delivering software. Frederick Taylor’s scientific management theory kind of says that people are lazy and stupid and as a result we need to make their work simple and we need to constantly monitor them. We need to separate work from management. Top down process on delivering software is based on premise that people downstream are increasingly pluggable and prone to make mistakes so we need to front load our process with all the smart stuff so there is less risk of something going wrong as we go further along. Since the price of defects increase the later it is discovered, we need big upfront design(BUFD). Plan, requirements specs, functional design, detailed design, test plans is hedging against the exponential cost of change, but this is in turn creates it and thus creates a reinforcing loop. There is no cause and effect, they both cause one another.

Meanwhile Deming’s premise is that people generally want to do a good job and take pride in their work and they respond well to an encouraging environment. Bottom up process builds business objects to represent business domain and then produces an architecture to wire them together.

Next Dan shares statistics that say that 60% of features are never or rarely used, 30% are sometimes used, and 10% to 15% are often or always used.

Then Dan explains that Behavior Driven Development is about implementing an application by describing it from the point of view of its stake holders. Only focus on high-value features, flatten the cost of change of anything at any stage, prioritize often, change often, adapt to feedback and continuously learn. Pull requirements as needed, evolve the design, code that can change, frequent code integration, frequent regression tests

BDD is derivative from XP (TDD, CI), Domain Driven Design, Acceptance Test Driven Planning (estimation based on building one scenario on top of another), Neurolinguistic programming (NLP), systems thinking.

BDD is getting the words right, enough is enough and more is waste while less is irresponsible, agreeing on DONE, outside-in (more systemic approach), interactions (series of interaction between people with different skills and software is an output of these interactions). People over process.

Dan next elaborates:

Getting the words right is domain driven design. Model your domain and identify your core domain (from the business side, the differentiator). Create a shared language and make it ubiquitous, determine its bounded context (things relevant in one context are totally irrelevant in another context) and think about what happens at the edges.

Enough up front thinking. Identify the desired outcomes, do enough to feel safe to estimate and keep a note of your assumptions, then “blink” estimate with people you trust because anything else is false confidence. Estimation is fractal – “don’t misunderestimate!”

A story is a unit of deliver usually follows the format as a role, I want feature so that benefit.

Try to focus on the value (NLP), in order to value, as a role, I want feature.

Agree on done by defining acceptance criteria as scenarios.

Code by example (TDD): start at the edges with what you know, implement outermost objects and operations, discover collaborators, working inwards and mock then out for now, repeat until DONE. This way we move further from the business domain into the technical domain.

Examples become codes test and documentation. Scenarios become acceptance tests which become regression tests.

Dan concludes that effective design and clean code has tangible stakeholder value, is delivered on time incrementally, is easy to deploy and manage, is robust in production, is easy to understand and communicate. BDD is a step in the right direction.

This presentation is available on InfoQ at