Upcoming Talks
February 28, 2007
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.
I’m delivering a keynote with Martin Fowler about the gaping crevasse between what business people ask for and what technical people think they want. I’ve presented with Martin a couple of times before – at least I know I’ll only be the second loudest person in the room.
ThoughtWorks is a “platinum sponsor”, which I think means we get to buy more drinks than the other sponsors.
BDD in Ruby at ACCU, 11-14 April, Oxford
ACCU is a conference by geeks, for geeks. With its roots in the C++ community, there are lots of strange people in weird industries like embedded systems, graphics engines and writing music software. It’s a refreshing change for me, where “enterprise systems” usually means moving data from over here to over there.
I’m actually at ACCU by accident, presenting behaviour-driven development in Ruby. They haven’t noticed yet that I haven’t touched C++ in ten years, and I’m not about to tell them.
However, the ACCU folks are developing a strong liking for dynamic languages – last year Guido van Rossum, the inventor of Python, delivered a keynote, and I co-presented a session introducing Ruby and Rails. So perhaps there’s life after the standard template library after all 
Coaching workshop and BDD session at Expo-C, 23-25 April, Gothenberg
You know the tutorial days that tend to happen either side of a conference? Well Expo-C has adopted the model of having mostly tutorial days and hardly any conference! The 23rd and 25th are tutorial days, with two speakers presenting full-day tutorials on each day (I’m on the 23rd). The middle day is made up of seminars by a number of presenters. As the only speaker who hasn’t published a book (one of the presenters, Jim Coplien, has a small library to his name), I can safely say it’s a very solid line-up. Also, it’s one of the smaller conferences so there is lots of opportunity to hang out with the presenters.
I presented a tutorial day last year around the theme of agile delivery and thoroughly enjoyed it. This year I’m doing something a bit different, focusing on “Change, Coaching and Communication”, using NLP and life coaching principles as the basis of a one day interactive workshop. As with last year, there won’t be any PowerPoint, mostly because I’m rubbish with PowerPoint.
I’ll also be presenting a behaviour-driven development session on the seminar day.
Keynote and SOA workshop at ROOTS, 25-27 April, Bergen (Norway)
I’ve not been to ROOTS before but I’ve heard good things about it. It’s a developer-centric conference and this year it features the likes of Kevlin Henney, Jim Coplien (who I’ll be racing to Norway from Expo-C) and lovely testing guru Linda Rising.
Erik Doernenberg and I are delivering a keynote on the nature of simplicity, and we’re running a three hour workshop looking at SOA for human beings.
Keynote and SOA workshop at ExpertZone, 23-25 May, Stockholm
I met Josefin Andersson, one of the organisers of ExpertZone, earlier this year and she convinced me I had to attend the ExpertZone Developer Summit in Stockholm. Since I’m scared of Josefin, I said yes. Also Microsoft’s Beat Schwegler will be there, and he rocks.
I’ll be delivering another keynote with Erik Doernenberg, based on our current pet themes of simplicity and clarity of intent (honestly, how hard can software be?), and running the workshop on SOA for humans.
I’ve been told by the Boss that I’m not allowed out of the house in June.
Monkey business value
February 15, 2007
So I was hanging out with a bunch of geeks in Switzerland, having one of those late night conversations, and an idea sort of emerged, and the more I thought about it, the more I liked the idea. And then I was thinking that a) I’m useless at following through on ideas and b) I would love someone to take this forwards. So here it is.
Our premise was that the value of automated testing is in its repeatability and low investment (in terms of human effort). However, running the same tests all the time just verifies that the system does a small number of well-known activities.
The value of exploratory testing, on the other hand, is to try all the weird combinations that people might try – aka monkey testing – in order to break the system by using it in unlikely ways. The problem is that exploratory testing requires people, so it’s slow and expensive.
Cue RMonkey (and possibly PyMonkey and JMonkey). RMonkey augments your Ruby acceptance tests, to emulate monkey behaviour. It works like this:
Boring, old-style test:
def test_user_can_login
web.navigate_to '/login'
web.enter_value :name, 'bob'
web.enter_value :password, 'secret'
web.press_button :login
assert_that web.current_page, has_title("Welcome")
end
Now we monkey it up, with the keywords usually, sometimes and rarely:
require 'rmonkey'
include RMonkey
def test_user_can_login
navigate_to '/login'
usually { web.enter_value :name, 'bob' }
sometimes { web.enter_value :name, 'kate' }
rarely { web.enter_value :name, random_string() }
usually { web.enter_value :password, 'secret' } # sometimes don't bother
web.press_button :login
sometimes { 10.times { web.press_button :login } } # bored bored bored!
assert_that web.current_page, has_title("Welcome")
end
So now you have automated monkey tests. There are default probabilities for usually/sometimes/rarely (say 80%, 15%, 5%) but that is customizable:
monkey_see :usually => 75, :sometimes => 22, :rarely => 3
The interesting part, of course, is to know what sequence of events leads to a test failure. A more fully-featured RMonkey would keep track of which events it executed and produce an informative narrative if things turned bad.
In the spirit of the infinite monkeys metaphor, this would prove most useful in a soak-testing scenario, whereby thousands of monkeys were hitting an application over an extended period of time. You would want to know that a) mostly it worked, and b) when it didn’t work, which sequence of events caused it to break.
Some obvious applications for RMonkey would be in driving Selenium or Watir, or using JRuby to drive JUnit, MarathonMan, WebDriver or any of the other Java testing frameworks.
The code for rmonkey.rb is simply:
module RMonkey
LIKELIHOOD = { :usually => 80, :sometimes => 15, :rarely => 5 }
def usually
yield if rand(100) < LIKELIHOOD[:usually]
end
def sometimes
yield if rand(100) < LIKELIHOOD[:sometimes]
end
def rarely
yield if rand(100) < LIKELIHOOD[:rarely]
end
def monkey_see(likelihood)
LIKELIHOOD.merge(likelihood)
end
end
So anyway, let me know if you would like to get involved in developing RMonkey. I think it's a really appealing idea and I'd love to see someone do something with it.
Tagged
February 12, 2007
Ok, so I’ve been blog-tagged. Twice in fact, by Patrick Kua and Mats Helander. Apparently the rules are that I have to tell you five things about me that you probably didn’t know, and then I have to tag a bunch of other people.
Except that this is the Interweb, blog-tagging is exponential and I’m usually the kid who gets picked last, so there are probably only about 4 people left on the planet who haven’t been tagged.
Anyway, here goes. Five things you didn’t know about me:
- I used to do origami. A lot. For years and years I would fold little squares of coloured paper (only squares, and only coloured on one side – I’m a purist) into all sorts of birds, beasts and useless household objects. My favourite was a turtle – you had to be pretty good to fold a turtle. It took me ten years before I could fold a jackstone. I kept going back to it each year until I suddenly got it. Then I made a whole load of them to prove it wasn’t a fluke. Then I forgot again.
- I love cycling. More accurately I love buying cycle-related toys like multi-tools, ever smaller and more powerful bike pumps, super-lightweight jackets. In fact, the sorts of things that make cycling more expensive than using public transport. When I’m feeling motivated I cycle 20km each way to work, usually 3-4 times a week. Right now I’m a lapsed cyclist – I haven’t cycled properly for a couple of months – but it’s only temporary.
- I play drums. I was in several bands over about 12 years, and played venues like the Rock Garden in London (tiny but lots of fun) and Dorking Halls in Surrey (to about 1000 people). A few years ago I started playing hand drums – bongos and an African djembe – which have the bonus of not needing a car to move them around.
- I got married in South Africa, on a wine farm near Cape Town. It was a fairy-tale wedding, with a horse-drawn carriage and ducks. Oh, and the bride looked amazing.
- I studied jitsu for several years. Once I got to a certain level – fending off kitchen knives, bike chains and a katana – I found I preferred teaching to grading (in fact jitsu taught me a lot about coaching). So I never got my black belt but I’m still double hard. So don’t make me come over there.
Right, I nominate Claudio Perroni, Paul Walker, Erik Doernenburg, Arjen Poutsma and Niclas Nilsson. You’re tagged!
Behaviour-driven stories
February 12, 2007
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.
