Tea-Driven Development

We have an old Kenwood Chef A701 that’s hardly out of use in our kitchen. A few days ago, the gearbox went. I bought a reconditioned one on Ebay for £23, and this morning I made the time to do the repair.

As I tinkered away with my screwdriver, I reflected on how grateful I was that the designers of this machine had made sure it could be maintained by an idiot like me. I actually made our A701 by cannibalising two broken machines, and I have always been delighted by how easy it is to work on.

Perhaps it’s my confirmation bias, but it seems that machines like this no longer tend to be designed with maintenance in mind. In our consumer society, we’re encouraged to throw things away rather than repair them, and globalisation ensures that is often the apparently rational economic decision to take: paying a local repair man to fix your DVD player will cost more than popping down to Tesco and buying a new one. Thank goodness for those cheap Chinese factories, eh?

If we don’t design our manufactured goods for maintainability, perhaps it’s no wonder we often feel like we’re swimming against the tide trying to persuade people that it’s important in software.

Last week I travelled down to London to the BDD Exchange conference. It was a one-day conference organised by Gojko Adzic and I had a great time. I missed Gojko’s talk as I travelled down from my cave in Scotland on the day, but I did arrive in time to see Chris Matt’s excellent lecture on what business analysis really should be about.

I particularly enjoyed the talk from Christian Hassa about teams failing to make BDD work. We can learn the most from failure, and Christian’s thoughtful analysis of what he’s observed in the field as a consultant with TechTalk is useful to any team trying to get the most from these techniques. The message of Christian’s talk very much echoed my own, that the tooling you use is entirely secondary to the collaborative relationship you need to build between the business and technical-facing members of the team. I was interested to learn about the tool, SpecLog, TechTalk are building to help teams with this problem, which seems to have many similar goals to my own Relish. It was nice of Christian to give Relish a name-check in his talk.

My session ran along the same theme as my talk from earlier in the year at Skillsmatter, describing the value of writing acceptance tests at the right level of abstraction, so that they describe business rules rather than implementation details. You can watch the session here.

I want to give you some news about the future of Relish. A lot has happened since we first started the project just over a year ago. Justin quit the project to concentrate on his new role on the RSpec core team, The Cucumber Book went into beta, and my wife gave birth to our second child. All of those things have meant that Relish hasn’t been able to progress as quickly as I’d have ideally liked, so thanks for sticking with us!

I’m still passionate about the vision for Relish, and as I teach training courses on using Cucumber and BDD, it seems to resonate with a lot of people. With The Cucumber Book pretty much behind us now, Relish will come back into focus and the pace will pick up again. I hope to have it launched by the end of the first quarter of 2012.

Here’s a rough outline of what we plan to do:

Usability & Information Architecture Enhancements

I have an IA specialist on the team now, and you may have noticed the first tweaks we’ve been making this week. There’s a lot to catch up, so we’ll focus on this until the existing features are polished to his (and hopefully your) satisfaction. Please let us know how we’re doing as we progress, and let us know if any of the changes annoy or delight you.

If there’s anything specific you’d like to see done that isn’t already logged in UserVoice, please add it there or reply to this post.

Test Results

Relish can’t deliver on the promise of living documentation until the non-technical readers can tell, when they’re looking at a scenario, whether it’s passing or not. We’ll be building a plugin for Cucumber that allows developers and testers to send their test results to Relish, so each scenario can be rendered with a big green tick if it’s passing. This will also enable us to start building all kinds of exciting dashboards for project managers to get a high-level overview of what’s going on.

Commenting / Feedback

Just being able to read features is not enough. I want Relish to be a collaboration tool, and that means that stakeholders should be able to comment on and give feedback about the documentation they’re reading.

RSS / Activity Feeds

People who want to stay up to date with changes to a project will be able to get a nice high-level summary via RSS, and possibly other means too.

Enterprise Install

As the codebase stabilises, I’m becoming increasingly comfortable with the idea of a stand-alone installer for customers who are not happy about having their features stored outside of their firewall. In the new year, I’ll be looking for a couple of friendly enterprise customers to help me shape this. If you’re interested, please get in touch.

Plans & Pricing

Yes, it had to happen eventually

When we come out of private beta (which is still a few months away), it will be with paid accounts for private projects. This is a hard call to make, and I’ll be in working with our beta tester community to get an idea of what they feel is a reasonable price to pay for the service. Public accounts like RSpec and VCR will continue to be free.

As always, I’m keen to hear what you think of these plans. Let me know in the comments.

As requested by JB in the comments to my previous post, here is some data about what happens when a team choose fine-slicing over estimation.

You’re about to see a CFD chart drawn by a team who used BDD to break down every requirement into scenarios before they started hacking on them. The items on the left aren’t actually scenarios in this case, they’re very small user stories which tended to be of a size of about 3-4 scenarios each. The point is, we broke everything down into the smallest pieces of behaviour we could, then re-assembled them into chunks that were meaningful enough to build together.

Rather than using story points to manage the variation in size of stories, we gave each story a value of one point, and used BDD analysis to try to ensure each story was a uniformly small size.

This data was collected over a period of about six months by a team of about eight developers. Their system (a high-volume website) was already live and they were adding features to it.

What strikes me the most is how straight the ‘done’ line is.

Before you write any code, start by brainstorming all the scenarios you’ll need to cover to make the story done. Do this collaboratively with everyone (devs, testers, UX, business people, product owner) who is interested in the story. Don’t try to make them valid Cucumber scenarios, just make a list of them on a whiteboard, index cards, or in a text file.

Now look at all the scenarios you have. Does the product owner really want you to build the product to satisfy all of them? Can you cut any out and defer them as another story to build later? Can you drop any of them altogether? Get rid of as many as you can until the story is as small as you can make it.

Now count how many scenarios you have left, and write that number on the story card. At the end of the iteration, count up how many scenarios you’re managed to deliver in total across all the stories you’ve done, and start using that as your velocity metric. It’s much, much more accurate in my experience than estimated story points. What’s more, the process of exploring the scenarios means you can agree a clear scope for the story before you get started.

Teams who are doing this well are getting things done much more quickly than they did before. Not only do they build a suite of automated regression tests, but they waste a lot less time writing the wrong code because of misunderstood requirements.

Would you like to learn how Behaviour-Driven Development can help your company get better at software development?

I’ve helped several teams learn BDD, and I’ve started to formalise the training I’ve been doing into a set of course modules. The modules aim to provide the foundations for a teamʼs successful adoption of BDD.

We start by immersing the whole team in BDD for a day to get everyone enthusiastic about the process. Then I take the programmers and testers and implement their very first scenario, end-to-end, on their own code. Now that we’ve proved it can be done, I work with project managers, product owners, and development leads, to streamline their agile process to get the best from BDD. We practice collaborative scenario-writing sessions, we learn how to use metrics to track progress, and how Kanban and BDD can fit into your existing agile process.

Please take a look at the course prospectus and get in touch to see how I can help.

I love using Cucumber to help me write software. I almost find it hard to imagine doing it any other way.

I want more people to discover this for themselves, so for the last year or so Aslak and I have been writing a book all about using Cucumber for Behaviour-Driven Development:

We hope we’ve captured some of the passion and sheer enjoyment we get from working with this amazing tool. Whether you’re a complete novice or an experienced Cucumber user, I think you’ll get a lot from the book.

What are you waiting for? Go and get yourself a copy!

Okay I’m bored of this. I need to talk about it.

I love to use Ruby, RSpec, Cucumber and Rails to do test-driven development, but my tools for running tests are just infuriatingly dumb. Here’s what I want:

• When a test fails, it should be kept on a list until it has been seen to pass
• When more than one test fails:
  • Show me the list, let me choose one
  • Focus on that one until it passes, or I ask to go ‘back up’ to the list
  • When it passes, go back up to the list and let me choose again
  • When the list is empty, I get a free biscuit
• When a test case is run, a mapping should be stored to the source files that were covered as it ran so that:
  • When a file changes, I can use that mapping to guess which test cases to run. Fuck all this naming convention stuff, it’s full of holes.
  • At any time, I can pipe the git diff though the tool to figure out which test cases to run to cover the entire commit I’m about to make.

When I say test case, I personally mean:

• An RSpec example
• A Cucumber scenario

…but it should work for any other testing framework too.

I feel like having a tool like this that I trusted would make a huge difference to me. There are all these various scrappy little pieces of the puzzle around: guard plugins, autotest, cucover, cucumber’s rerun formatter. None of them seem to quite do it, for me. Am I missing something?

Or shall we make one?

If you work in a regular weekly iteration rhythm, it’s quite normal to think about starting the week with a planning session, and ending the week with a retrospective. I have a new idea for you, which my team have just happened upon, but which I rather like: Swap them around.

Instead of trying to reflect at the end of the week when you’re tired, leave it until Monday morning. You’ll be fresh, you’ll have had a chance to privately reflect on the last week over your weekend. Crucially, when you leave the meeting with new ideas about how to work, you’ll have a whole week ahead of you to try them out.

Instead of leaving work at the end of the week with no clear idea what you’ll be doing the next, get ahead of the game and make a plan before you leave on Friday. You’ll have prepared the ground for getting down to business almost straight away when you walk in on Monday morning, and I suspect this means you’ll enjoy a more relaxing weekend too.

I’ve never looked at things this way before, but now I do it makes perfect sense. Why not try it and let me know how it works for you?

Recently we had a user who runs the relish gem on JRuby, and needed jruby-openssl to be loaded. He kindly submitted this patch, which I merged in without really thinking about it too much. Then the problems started.

That’s not the right way to express dependencies for different platforms using RubyGems and Bundler. I’ve done some research and I think I understand the current good practice for this, so I’m going to document it here.

The .gemspec is read at the time you build and release your gem, so any conditional logic in that file will be evaluated once when the gem is built and released on your machine. So a line like this:

s.add_runtime_dependency('jruby-openssl') if RUBY_PLATFORM == 'java'

Will bake-in the dependency based on whatever platform you run gem build on.

What you need instead is to evaluate the platform at runtime. Bundler offers you a way to do this, in your Gemfile:

platforms :jruby do
  gem "jruby-openssl"
end

What a jruby user will now experience is that when your gem is loaded, they’ll see a warning:

→ relish help
JRuby limited openssl loaded. http://jruby.org/openssl
gem install jruby-openssl for full support.
...

It’s now up to the user to manually install the gem themselves. It seems a shame that there isn’t any way to specify this information in the gem’s manifest, so that it can be installed on a platform-specific basis when you gem is installed, but as far as I can tell there’s no way to do that right now.