Agile

It’s now about two weeks to OOPSLA, where Liz Keogh and I will be presenting a workshop on behaviour-driven development using JBehave. This will be along similar lines to the workshop I co-presented at RailsConf Europe last month.

So it’s that time of year again. I’ve got a number of conferences and workshops coming up, ranging over all sorts of topics. I just popped over to Martin Fowler’s site (I’m doing a talk with him this week) and noticed that he has a much more organised setup than me. All his events are in a sidebar and there is a handy link if you want more details. Another idea to go on my to-do pile.

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.

How about that? You wait ages for a BDD framework in .net and then two come along at once! Ok, to be fair NSpec has been around for a while. However I’m talking about describing application behaviour in terms of stories and scenarios, to complement NSpec’s description of interactions between objects. (As a side note, I would love to see NSpec adopt rspec’s describe/it vocabulary rather than using contexts and specifications.)

Introducing NBehave and, well, NBehave! ¶

Morgan Persson first spoke to me about writing a .net version of JBehave at the beginning of 2007¹, so I am delighted that he has just announced his first public release of NBehave. It mixes C# and VB.net in a lovely it’s-all-about-the-CLR way. So the examples are in C#, extending VB.net framework classes.

It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.

This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.

RBehave is a framework for defining and executing application requirements. Using the vocabulary of behaviour-driven development, you define a feature in terms of a Story with Scenarios that describe how the feature behaves. Using a minimum of syntax (a few “quotes” mostly), this becomes an executable and self-describing requirements document.

BDD has been around in the Ruby world for a while now, in the form of the excellent RSpec framework, which describes the behaviour of objects at the code level. The RSpec team has focused on creating a simple, elegant syntax and playing nicely with other frameworks, in particular Rails and the Mocha mocking library.

I’ve got a number of tutorials, conference sessions and keynotes coming up over the next few months that I’m very excited about. My themes for this year are behaviour-driven development, SOA for human beings and understanding what simplicity really means. Looking at these, there is an overarching theme about getting different kinds of people talking to each other in plain English (for some value of English).

Keynote at QCon, 14-16 March, London ¶

QCon is the London version of the excellent JAOO conference in Denmark, which has become my favourite technology event of the year (apart from phone upgrade time). They attract world-class presenters to provide sessions varying from the deep technical through to people and process topics, and they’ve done the same with QCon. What’s more, they have managed to resist the lure of the sales-pitch session, which means you get to hang out with other geeks without people trying to sell you stuff. The London event is being run in conjunction with the common-sense guys at InfoQ, and I’m lucky enough to be speaking there.

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’ve been having difficulty recently with a trend I’m seeing on projects. What happens is this: we (an agile development team) engage with a client for a short period—typically 2-4 weeks—to investigate how we might work with them to solve their problem. During this period, we drive out lots of stories, do some technical investigation and estimation, and out of this we generate a high level release plan. All very good, you might think. But then, unfortunately, everything is mysteriously forgotten about except the release plan, which suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan. Well ok, it’s not quite that dramatic, but it certainly doesn’t feel very agile to me. Hopefully I can explain why.

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.

When Darwin’s “On the Origin of Species” was published, evolution was already a well-established idea. Darwin’s insight was that evolution—through the process of natural selection—led to the introduction and extinction of entire species. This of course upset the established church, and to this day there are still religious groups who reject the idea, in the face of overwhelming scientific evidence.

The early twentieth century saw the rise of “neo-Darwinism”, which finally provided a mechanism for natural selection. It wasn’t happening at the level of creatures but at the microscopic level of genes. Natural selection is simply the playing out of a long-running stastistical game based on shuffling genes, and more disturbingly the creatures themselves (and ourselves) are just a very sophisticated form of temporary accomodation for those genes!

Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).

Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.

This question came up at the recent Expo-C conference, when presenter Michael Stal talked about designing services to be “as simple as possible but no simpler”. Kent Beck advises us to do “the simplest thing that could possibly work”, but this is often mistaken for “the first thing I could possibly think of” or even “the only thing I know” (also known as the Golden Hammer antipattern).

We picked up the topic as an open space session later that day. I took the position that you should only ever focus on the specific case in hand, and then only generalize if you meet another similar case. Erik Meijer, the reknowned language guru and thoroughly nice guy, took the opposing stance that you should abstract the general solution and then implement it locally. He pointed out that this was an approach with centuries of mathematical tradition behind it and is a fundamental tenet of modern functional programming¹. This developed into a good-natured but heated stand-off. I just couldn’t see the value of building a fancy general solution on the client’s money, when there was lots more important work to do and limited time. He couldn’t understand why you wouldn’t take the effort to make something as flexible as possible for the end user, especially if you were designing something like a programmers’ toolset or language. On the scale of specific to general—or concrete to abstract—we were at opposite ends, with a seemingly intractable chasm between us. He was simply wrong, and so, of course, was I.

Adopting agile practices is a step-change for many senior managers and business sponsors. Don’t underestimate the importance of getting them onside early in an engagement, and making it “safe” for them to explore and adopt agile practices.

Automated builds have become a cornerstone of agile development. Every time a developer checks in a change, a tool like Cruise Control checks out all the sources, builds everything, runs all the unit tests and reports back with immediate feedback. This cycle has become known as Continuous Integration, due to the seminal paper by Martin Fowler and Matt Foemmel, but this is something of a misnomer. It is better described as Continuous Build. (Their use of “integration” was about integrating all the bits of software that the various programmers in a team would traditionally be working on in isolation from one another, only to bring together and spend days or weeks getting to work. Practices such as pairing and automated builds have all but eliminated this form of integration hell, at least on agile projects.)