DanNorth.net

Last October I was privileged to give a keynote talk at the Øredev conference in Malmö, Sweden. It was a late substitution. The original speaker, testing guru James Bach, had to cancel at the last minute for personal reasons. I felt pretty intimidated stepping into his shoes, especially since the other keynote presenters were Joel Spolsky and Andy Hunt, but I figured since no-one had heard of me I’d probably slip under the radar.

James was planning to talk about best practices, and it seems we have similar opinions about them. I would encourage you to read his wonderful blog article where he rigourously deconstructs the phrase¹, and then just as eloquently picks apart the arguments of anyone who disagrees. So I thought I would do something around the same topic.

I wrote it up as an article and the kind folks at InfoQ published it, and the Øredev team has put up a video of the talk. (For some reason I can’t get it to work in firefox on ubuntu, but I’m pretty sure the guy on the left is me).

¹ I didn’t realise until long after Øredev that he was the author of that article. It made me very happy when I found out.

Earlier this year I wrote an article to introduce service-oriented architecture to non-technical people. It was published in the May 2007 issue of Better Software magazine.

The kind folks at Better Software have allowed me to provide a PDF version of the article, complete with retro 1950s graphics. You can also read it as a single html page.

Please post any comments here, because I’ve disabled comments on the page itself.

At a recent software architecture workshop, I was discussing the ideas behind BDD with a great group of people (more about that soon). One theme that kept coming up was the fact that I needed to write much more about BDD as an entire methodology, and to address the current perception that it is just a repackaging of test-driven development (which, to be fair, is where it started).

As I was describing the workings of BDD, I discovered that I had made the assumption that everyone knew what a Story was, in the agile sense of defining a requirement. It turns out that there’s a whole world outside of my little bubble that use all sorts of different processes for identifying and defining requirements, and in particular they don’t know what I mean by a Story, nor why they should care.

I was specifically asked what a story was from a behaviour-driven perspective, so I have written it up in an article called What’s in a Story?.

In the interests of releasing early and often, I will be editing and updating it in response to comments on this post. I’m particularly interested in people’s thoughts about how BDD stories compare to Use Cases. I’ve read a bit about use cases and used them a long time ago, but I haven’t been around them recently enough to really remember whether I liked them.

At the beginning of this year I wrote a feature article for Better Software magazine, which was published as “Behavior Modification” back in March.

The article is now available on my site. It gives an overview of behaviour-driven development, from its origins as a coaching aid for TDD through to its current form as a proven, comprehensive development approach.