Building examples collaboratively using business language

It is with some trepidation that I write this. Brian Marick is one of the original signatories of the Agile Manifesto and has been saying wise things about software development for almost as long as I’ve been writing software. I follow him on Twitter. I’ve even bought the book he hasn’t finished writing!

So, I was quite surprised when I read his tweets the other day.

“I bet no non-technical person will ever read this cucumber test. Which makes writing it a tragic waste of the best years of my life.” @marick 30 July 2012

I totally agree that Cucumber tests, and all business facing tests, need to be of value to the business. There’s no point couching a technical test in business language just to be with the cool kids. (As an aside, given that writing a test couldn’t possibly take years, I can only assume that he feels that writing it somehow invalidated his contributions over the previous decades. Get a grip, Brian! No need to be melodramatic 🙂

“The overuse of Cucumber is the most mysterious mystery of the Rails world, next to the use (at all) of vim.” @marick 30 July 2012

Overuse of anything is bad (TM). (That’s the meaning of prepending the word use with the word over.) Again, this seems to refer to the inappropriate use of business facing tests, and I can but concur (again). Use of Cucumber, and other BDD tools, is on the increase, not just in Ruby, but in other development stacks too (SpecFlow in .NET, Cucumber-JVM and JBehave on the JVM) and I see this as a good thing (TM).

I’m more ambivalent about the vim pronouncement. This is geek cliché in the guise of trolling, and I hesitate before responding in any way at all. But I’m a brave (or foolish) man, so here’s a tangential anecdote. At the ACCU 2007 conference, Jez Higgins (@jezhiggins) organised a small squash tournament. The 2 teams were emacs and vi and he’d had t-shirts made for the players. None of the participants seemed too bothered which team they were on, so it was purely chance that put me on the emacs team. We won. I’ve still got the t-shirt (somewhat faded) and I still use vim (or gvim) more often than emacs (though that’s not saying much).

“For those unfamiliar with All Things Me, I am *down* with collaboratively building examples using business language… I just want to do the work around the whiteboard, and then have programmers translate the results into nicely readable Real Code.” @marick 30 July 2012

Here’s the nub of the problem. The requirement gets discussed at the whiteboard; everyone understands it perfectly; the developers deliver a high fidelity code version; everyone goes home happy. And of course the code is readable, so when, several months later, the business people ask *what* exactly the system does (in preparation for a change request), someone can do a reverse translation and tell them. Really?

Maybe I’ve just not worked with good enough teams, but that’s not what I see. I see plenty of different development processes (anything from light-weight user stories to business requirement documents inches thick) that may (or may not) have once been implemented (more or less) correctly, but that are (at best) verified by a few flaky Selenium tests and a bucket of manual test scripts that get rolled out every now and then to slow down the release process.

I see tests that get taken out of the build because they’re no longer green and the current team don’t know what they’re testing or whether they’re worth fixing.
“How does this work?”
“Beats me. The guy that wrote it left”

I’ve read Brooks and I know there are no silver bullets. I’ve been around long enough to know that no method is better than the team that’s using it, but some ways of working are more forgiving than others. And in the same way that the wisdom of groups is improved simply by having a diverse group, it seems to me that the software development process is also improved by diversity – namely by involving the business intimately throughout.

Writing tests in business language is more than just collaboratively writing examples. There’s the whole process of domain discovery with the development team helping the business. There’s the invaluable executable specification that can demonstrate that what you thought you understood was actual understanding. And there’s the added bonus that when we come back to change the system later, the tests are written in a way that the business understands, so that when the tests go red (as they surely will), we can ask people who know and care whether this is one to keep or one to bin.

[Apologies if my overuse of parentheses offends – it was just the mood I was in]






One response to “Building examples collaboratively using business language”

  1. mattwynne Avatar

    I’ve personally experienced a great maturing happen in teams that started using Cucumber scenarios as their shared Source of Truth. I’ve seen a much greater trust and empathy develop between the business-facing and technology-facing sides of the team when they built and used those scenarios collaboratively.I’ve also found time after time for myself that, when the scenario does eventually fail, it’s much easier to understand the implications when the test is written in plain English.I share Brian’s concerns about the added complexity of step definitions that map from your plain-English scenarios to concrete actions against the system under test, but I’m increasingly wondering whether that complexity is in itself a smell: I think we should be able to consider the Cucumber scenarios to be just another client of our application. If the step definitions are doing complex things, that’s often complexity we should be pushing down inside the application.This is a question I’m hoping to explore with my [Hexagonal Rails]( blog post series.

Leave a Reply

Your email address will not be published. Required fields are marked *