What’s the point of BDD again?

I recently sent out a link to Bob Martin’s post on how BDD is similar to finite state machines.  My main reason for doing this is because my office has a decent enough faction of Uncle Bob fanboys that I knew by doing that I’d keep them occupied for a while trying to resolve the cognitive dissonace of “BDD is hard, but Martin likes it” which would give me a window to work with the folks who were generally interested in it some extra coaching.

The unintended consequesce of that, however, was that some people who were having problems with verbalization latched on to the FSM idea and thought “If I just make FSM tables, I’m doing BDD too!”

The problem is, that’s horsefeathers.  The most important part of Behaviour Driven Development is the Behaviour part.  The aspect of having to think like the end user and communicate requirements in their terms is where the value comes from.  This is where Martin’s attempt acctual does more harm than good:  by attempting to relate BDD scenarios in terms that programers will feel comfortable with, he give license to developers to strip away the most valuable parts of it and continue on business-as-usual.

I can manage this issue, because the person in question isn’t typically responsible for generating scenarios or requirements.  But pay attention:  as soon as people start trying to strip away the behaviour to just define requirements, they are missing the entire point.  Only “Bad Things” can come down the development cycle as scenario by scenario the end user is removed from consideration once again.