In reply to @otfrom & @ptexpat about http://dannorth.net/2012/05/31/bdd-is-like-tdd-if/

I don't know a lot about BDD.  When I last heard someone talk about it, it sounded to me like it was an attempt by BA's to wrest control of the development process from developers (isn't driven, just another word for "controlled"), to somehow MAKE the developers write the right kind of tests rather than "lazy" hard-coded tests that would pass in the narrowest of cases. Sure this is some kind of smell.  It kind of reminds of intricate attempts to engineer workflow and fields and flags in Jira, the imagined aim being that nobody ever has to talk to each other ever again.  But maybe I'm caricaturing.  What I hope it is, is a bunch of tactics to make sure that the conversations that happen around a story are as rich and informative and useful as possible (specification by example, sounds like it might be something like this).

The truth is, if anybody has control of the process, if any stage of the process is "Driving" and is insensitive the vagaries of the other parts of the process, the process is in trouble because it isn't accruing vital information.  Everybody the whole length of the process needs to add value.

Similarly, I'm suspicious of anybody who claims that anything is "just" something else.

Both TDD and BDD need to be seen as tactics within an Agile, iterative, empirical, "inspect and adapt" strategy. If they are held up as strategies, they run the risk of encouraging the belief that the world isn't vague, complex and at least initially un-knowable, that we aren't always in software, working on the borders of the "Complex" and "Chaotic" sectors of the Cynefin framework.

Well, we are.

Posted via email from The Ginger Mumbly