BDD, how I wish you did not exist.

I read a blog post that got me all bent out of shape and I decided to replicate my reply on the blog. 

"Shipping software is the goal, and the practices are a means to an end. The focus on shipping is no excuse for cutting corners, but perfect adherence to the practices is no excuse for not shipping." (Kent Beck:http://www.threeriversinstitute.org/JustShip.html)


This conundrum of whether or not "high ceremony development" is an valuable agile practice at start ups is interesting. I was not present at RejectConf 2011 but I will infer what Obie's comments were from that blog post you are referring to. As I understood it Obie was saying that using BDD tools like Cucumber or FitNess are a waste of time if they add little insight into the business domain. Let's explore this idea a little, what value does a business get out of a Cucumber Suite if your entire business domain is as simple as the Rails Blog Post Demo Crud App? What about the other extreme, what if they are still experimenting with new ideas and are actually creating a new domain? Most startups are coming up with ideas that they haven't really flushed out yet and still have to test the market and the Lean Startup community can tell you that there are better ways of obtaining that information without having to write "BDD" suites.  

Personally I feel that BDD has caused a great deal of confusion and cargo cult culture in the software community. Dan North made a conscious decision to rebrand test driven development to behavior (or as the Brits spell it behaviour) driven development in order to make it more amenable to his teaching curriculum. In his own words:

"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. My response is behaviour-driven development (BDD). It has evolved out of established agile practices and is designed to make them more accessible and effective for teams new to agile software delivery." (Dan North:http://dannorth.net/introducing-bdd/)

Then BDD became a matter of pride:

"At the end of 2003, I decided it was time to put my money – or at least my time – where my mouth was. I started writing a replacement for JUnit called JBehave, which removed any reference to testing and replaced it with a vocabulary built around verifying behaviour. I did this to see how such a framework would evolve if I adhered strictly to my new behaviour-driven mantras. I also thought it would be a valuable teaching tool for introducing TDD and BDD without the distractions of the test-based vocabulary." (Dan North:http://dannorth.net/introducing-bdd/)

The original problem that Dan was trying to solve was that he felt like there was too much of a blank canvas and that there was too much of a focus on "testing". He wanted to give people a template to make it "easier" to get started with "testing" but now it has evolved into something different. "Over time, BDD has grown to encompass the wider picture of agile analysis and automated acceptance testing." (Dan North:http://dannorth.net/introducing-bdd/)

That is one of the things that I dislike about BDD tools and the cargo cult culture around them. To assert that these tools are the catalyst for a collaborative relationships between developers and their customers/product owners is absurd. There is NO guarantee these tools help developers gain deeper insight into a business domain. Thats what practices like planning, sitting together, ubiquitous language, whole team, user stories, customer examples, demos, and frequent releases try to address. The only tools that I know of to help with gaining insight are hard to automate, they are communication and feedback.