This post originated from an RSS feed registered with Ruby Buzz by Brian Ford. Original Post: Behavior-Driven Collaboration Feed Title: def euler(x); cos(x) + i*sin(x); end Feed URL: http://feeds.feedburner.com/defeulerxcosxisinxend Feed Description: euler(PI) # => -1 Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Brian Ford Latest Posts From def euler(x); cos(x) + i*sin(x); end

Eegads, how time flies. At the March 6th meeting of pdx.rb, I gave a short talk introducing BDD (Behavior-driven development) with a couple examples from RSpec. Since David Chelimsky has already done a terrific job writing an introduction tutorial, I decided to focus more on the big picture of BDD. My take is that BDD is some rather sweet glue that can foster collaboration across the spectrum of folks involved in software development, from clients to designers to developers to users. So far, we���ve got a lot of turf wars going on, and as in any war, there are casualties. In software there are crappy products, tortured users, unhappy developers, exasperated designers, cost overruns, and misunderstandings galore. BDD isn���t some magic salve that can be slathered on a messy process like butter on a toasty English muffin and make it all better, but I do believe it has promise.

So, here are the slides from my talk. (Right-click and Save As��� Sorry, MIME types are not set right at the moment.) Unfortunately, in a tremendously idiotic move born of high stress, I deleted the original slides before I had uploaded them. Fortunately, I had some notes and a partial earlier draft, so I was (mostly I hope) able to reconstruct them. There is unfortunately no audio from the talk. As with most slides, these are marginally useful without it, but browse and feel free to ask questions.

There is one part that seems highly promising to me and easily attainable now. As you know, RSpec allows you to spec the views separately from the controller. This is a fantastic tool that interaction designers could use to communicate with developers. The syntax that an interaction designer would need to learn is fairly simple (most interaction designers are not developers), and you shouldn���t have much (if any) conditional code in your specs anyway (conditionals being one of the more difficult parts of programming to get right in my experience). The specs can accompany wireframes and provide another artifact of communication that bridges the different domains of interaction/interface design and development. Exciting stuff.