I had a much longer review planned initially, but am instead just going to write down a few notes here.
Really short version: do not watch this thinking you are going to learn how to do BDD.
Rob’s latest entry concerning BDD is really disappointing on a number of levels. He ‘introduced me’ to BDD through his Kona webcast originally, and so I generally look forward to anything he has to say about the subject, but the overall quality of this online course was pretty lackluster, in many respects.
He starts off strong, pointing out that BDD really has nothing to do with tools or frameworks, which is spot on.
He then undercuts this throughout the rest of the webcast with his use and championing of NCrunch, a tool in search of a need <digression>seriously, I’m sure that someone could make an argument for this tool, but if you are developing such that you need ‘instantaneous’ feedback on whether your tests pass, you are doing it wrong</digression>, that also doesn’t appear to work as expected (there’s a seeming litany of “I wonder if this is working right” comments in the webcast, which seems significantly less polished than many of his previous efforts).
But moreover, a developer dicking around writing code in the absence of clear requirements and interaction with business users is what I would currently consider to be the antithesis of what BDD is all about (and no one gives a shit about emailer code anyway). There’s nothing worse than a developer designing any sort of significant business impacting code without working with the business. Ok, I take that back, a group of developers doing this is worse (which I experienced recently).
Some developers seem to regard the end users of the software they write as idiots who don’t know what they are doing. I understand this, because, let’s face it, sometimes it seems pretty accurate. But, more often than not, it’s the end users that know what they are doing, regardless of how technologically savvy they may happen to be, and it is they who know what code needs to be written (even if/though they wouldn’t know how to write code to save their lives, but I digress).
To be (somewhat) fair, it would be difficult to create an easily consumable webcast that shows how proper BDD is to be done. “Hey Bob, how should this software work?” “Well, Steve, it needs to do thus and so.” “Well, thanks Bob!” Not very compelling on the face of it.
But, caricatures aside, that is what proper software development is really all about, a collaborative interaction between developers, end users, stakeholders, and the like.