One of the main reasons I was drawn to adopt Ruby as my primary development language last year was the RSpec story runner, a fledgeling project to bring developers and users closer together with executable specifications that are easy for both humans and machines to read. I was really attracted to the community around these tools and the energy and focus they were putting into bridging that communication gap, and wanted to be a part of it.

18 months on and the RSpec story runner has matured into Cucumber, a hugely popular open-source tool for executing these tests. Ruby has made an excellent platform for Cucumber, the flexibility of the language and the collaborative open-source culture around it meaning the tool has matured rapidly, with over 177 different people contributing code to the project to date.

Over the summer, Cucumber began to speak to applications written in other programming languages than Ruby, by adding an adapter mechanism for the language in which the step definitions (the glue code which actually pokes around with your app) are written. Firstly this was done with JVM languages so that when Cucumber was run under JRuby, it could test an application via step definitions written in Java, Groovy, Clojure or Scala.

This still left .NET teams out in the cold though. One approach would be to run Cucumber under IronRuby but having tried some experiments with it, it feels like the slow boot-up time of IronRuby will make for frustrating TDD cycles right now. In response to this, I hatched a plot with Aslak Hellesoy, the creator of Cucumber, and Richard Lawrence to create a generic wire protocol for Cucumber which would allow it to invoke step definitions against a remote service written in any language. Over the last few months Richard and I have worked on the protocol, and at the same time Richard has built the .NET tool (Cuke4Nuke) that allows you to implement and serve up your step definitions in C#. Richard has just published an excellent short screencast which shows how to use it. If you’re writing .NET and would like to enjoy the warm glow of Cucumber, you owe it to yourself to take a look.

As a coach, I like to introduce new practices only when I can offer them as a solution to a problem that the team has identified for themselves. On my current team we’ve been tracking our Work in Progress (WIP) for some time, but we’ve never taken the step of systematically limiting it.

At a recent retrospective it became clear that everyone was feeling the strain of having too many things going on at once:

• Our velocity was really bumpy, with no releases for days at a time, then suddenly several stories going out at once in a big batch.
• Our QAs, who run final checks on stories before they go live, would be periodically hit by a tidal wave of work when one of these batches came through
• Stories would languish in the ‘nearly done’ stage, with developers too distracted with new work to finish off final copy changes and tweaks.
• There was a general feeling of being constantly distracted.
• We were doing less pairing than we wanted: the person you wanted to pair with always seemed to be doing something more important.
• We weren’t getting as much done!

We all agreed it was time to set a WIP limit.

So we studied our Cumulative Flow Diagram (CFD) chart, and looked back for a time when we’d been more productive. We used the measured WIP from that time as our new limit, and stopped taking on any more work until we’d drained down our number of stories in progress to that limit.

Here are the benefits we’re now enjoying:

• Our delivery velocity is smoother
• We’re pairing more again
• Our stand-up takes a sane amount of time, and people aren’t fidgeting and bored because what’s being discussed is more relevant to more people
• The cycle time to get a change through the build and into production is now way shorter

It’s too early to say, but I think we’re also starting to get more done again. Little’s law would certainly indicate that this is a likely outcome.

XtC are pleased to announce the 9th consecutive London XpDay:

The Agile community has grown and matured over the years we’ve been running XpDay, so now we want an event that helps practitioners collectively advance the State of the Art.

The first day will consist of programmed sessions, the second day will be an Open Space where attendees will discover more about the topics that interest them most. We have three remarkable keynotes lined up for this year: Mark Striebeck, Doron Swade and Terry Saunders. Of course, we’ll still have our famous evening social events.

— from Rachel Davies

The cost for the conference is £350. Highly recommended.

Scheduled Programme: http://www.xpday.org/programme

Booking Form: http://booking.xpday.org/registration.php

London XpDay: http://www.xpday.org

We all like usable software, but what about usable code? How do we test the usability of the code we write?

One way is to get another programmer to work with it. If a bug is discovered in some code you’ve recently written, instead of just quickly fixing it yourself, see how easy it is for someone else to fix. Write a failing test that isolates the bug, find a pair – ideally someone who has been working on something completely different – and let them loose on your code.

Try to resist telling them where to look – watch how easy they find it to navigate the code, find their way around it. Listen to their comments, and encourage them to start making little changes – rename things that don’t make sense to them, for example. Hopefully you were pairing when you wrote the code in the first place so the design will already reflect two people’s perspectives on the problem, but you often need at least three people’s input on a design before it really starts to become usable.

CITON (Continuous Integration and Testing Conference) Europe was one of my favourite conferences last year: A chance to hang out with some very thoughtful and experienced people in a close-knit setting. CITCON US has just announced the venue and dates. The conference is amazing value – free! – but the 150 places go fast, so keep an eye on the mailing list for when registration opens.

Organised and facilitated by Elizabeth Hendrickson this was a great group of people to meet with. Elizabeth ran the day as an open-space, a format which I really enjoy, and which worked very well for such an interesting, intelligent and enthused bunch of people.

I came away from the day having had the chance to discuss, in depth, some ideas that had just been floating around in my head as vague notions. This is the really great thing about getting groups like this together – you find that there are actually other people who you can talk to about these crazy ideas.

We also came up with a fantastic new feature for Cucumber. More on that later.

Long-running acceptance tests suites are a problem we’ve spoken about before. Following these discussions, I’m now more convinced than ever that the feature missing in most of our automated acceptance testing tools right now is memory. By remembering test results from previous runs, and ideally the source code changes that were associated with that run, we can build a model of the tests and their relationship to the code. We can use this to help prioritise the tests to optimise for failing fast – pick the tests most likely to fail and run them first. This is the strategy JUnit max has adopted, and it really makes sense to me. I look forward to getting some time to develop these ideas further.

I ended up in a session about using Cucumber with .NET which I think Aslak and I had both expected to be about explaining the new abstraction of ‘programming language’ in Cucumber, which allows step definitions (the glue that allows the cukes to drive your app) to be written in a variety of languages. In fact, the feedback we got from the assembled was that it would be even better to offer a generic ‘wire level’ language. This would then allow people on any platform at all to work with Cucumber – currently only platforms that run Ruby will work – and to write their step definitions without having to touch Ruby at all.

This is an idea that could only have emerged by getting that group of people together. Richard Lawrence and I paired up there and then and got to work on the new feature, which I fleshed out during more pairing sessions during the week with Aslak and Richard. Watch this space for more details as we get this working.