DanNorth.net

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.

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.

Now, Dave is a programmer. What’s more, he is a very thoughtful programmer, which means he invests a lot of energy in making programming productive and effective – and more importantly fun – for himself and other programmers. He doesn’t get very excited about capturing requirements or the dynamic between testers and analysts, so you won’t hear him talking about the wider context of BDD, but you will hear him saying that there is one!

BDD is fundamentally about identifying behaviour. At the analysis level, the behaviour of a story is its acceptance criteria, which BDD expresses in the form of automated scenarios. You need analysts working with testers to capture the stories and identify the acceptance criteria, and then you need programmers working with testers to automate the scenarios.

So the ironic twist is that all that talk about “testing” in TDD was taking the focus off the real testing action! My efforts to put the word “test” back in its box have in fact propelled the testers into the central role on a BDD team.

So the message here is twofold. Firstly, although a lot of the existing BDD message is in the TDD space, don’t lose sight of the bigger picture or you’ll miss out on all the good stuff. And secondly don’t underestimate the value of the testers on your team: they are your direct line to delivering high value software.

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.

If you are working on an agile project, you can confidently take the “simplistic” approach of only solving for today, safe in the knowledge that you can easily change the code tomorrow, or next week, as you learn more. If you are designing something that involves publishing an API – of which designing a programming language can be considered an extreme example – then your decisions can have a far-reaching impact².

This led us to the notion of a Change Event Horizon, which is the amount of time before you can undo the effect of a decision. For a programming language the change event horizon is huge. It can take years to repair a bogus language decision, and involve complex processes such as deprecation. For an internally-deployed enterprise app you are only as far away as your next release date.

So now we had a working definition of “too simple”. It can be defined as any decision that doesn’t consider the scale of the change event horizon. As an agile developer, one of my objectives is to create as small a change event horizon as I can, through the medium of continuous integration, automated testing and regular user feedback. Erik doesn’t have that luxury – he has to predict what his users will want, and use much blunter instruments such as beta programmes and focus groups. Add to that the myriad unpredictable things people do once you release a language – who would have predicted that Ruby would become the DSL host language of choice, or that VB would ever become cool³ – and you can quickly see that Erik lives in a far more complex world than me. No wonder then that he looks to the general, abstract case whenever he encounters a new situation. And I can rest easy knowing that my tiny change event horizon means I can change the world with the next release.

NLP talks about “in time” vs “through time”. Being in time means living in the moment, and not worrying about the future. Being through time means seeing the wider context, and carefully considering the implications of any action. Of course most people are a healthy mix of both of these. I am notoriously in time, which might explain why the immediacy of feedback on an agile project appeals to me – I simply don’t have the attention span for anything longer!

¹ Erik is also the father of Haskell

² Thanks are due to Niclas Nilsson for taking the role of translator/peacemaker for us to reach that realisation.

³ Take a look at some of the up-coming language features in VB9 if you don’t believe me.

I was lucky enough to attend the Software Architecture Workshop in Cortina recently. It was a three day workshop based around the idea of Open Spaces, which involves handing the asylum keys to the inmates and seeing what happens.

I convened a session called “What’s so hard about Event-Driven Programming?” to explore the experiences of the other delegates in designing, implementing and testing asynchronous, event- or message-driven systems. I took the position that actually it was all very straightforward as long as you followed a few basic principles. Another delegate, Mats Helander, took the opposing view that asynchronous, event-based systems could develop scary emergent behaviour that would lead to a world of hurt. (more…)