In the run-up to CukeUp! 2015, we caught up with BDD expert and enthusiast Tom Stuart to ask him about his talk and what he thinks of the current state of BDD. Tom is a computer scientist and programmer. He has lectured on optimising compilers at the University of Cambridge, co-organises the Ruby Manor conference, and is a member of the London Ruby User Group. You can find him on Twitter here, and visit his website here.
You’re leading an open-discussion at CukeUp that’s looking to define what BDD actually is. Can you give us a brief overview?
The title of the discussion is “WTF is BDD?”, and the idea is to try to get everyone to agree on a simple, clear, concrete description of what BDD is and literally how to do it. I don’t know if that’s a realistic goal, but I thought it would be interesting to try.
Where did this need to redefine BDD come from – what has led you to this talk?
It’s not about redefining it so much as just nailing down a usable definition in the first place. I honestly don’t think we have one right now and I find that frustrating.
The term “behaviour-driven development” has mostly worked well for discussions between experts — primarily this means consultants and trainers — because the people involved in those conversations know how things have been done differently (and badly) in the past, and are able to use that experience to interpret, frame and prioritise the whole cloud of ideas that swirls around BDD.
But I’d say there’s been a failure to communicate the essential idea of behaviour-driven development to the wider non-expert community, which is a shame because it’s the non-experts who stand to benefit the most from it. I find BDD very useful but I also find it difficult to persuade other people to do it because there’s nothing to point at to show them what I’m talking about. That makes it look like it’s not a real thing. It‘s embarrassing.
Right now the only guaranteed way to “learn BDD” is to pay one of those consultants or trainers to come and teach it to you, which is fine in itself, but it shouldn’t be the only option. If BDD has validity and value then we should be able to communicate it straightforwardly, without jargon or enterprise-consultant-speak.
And even among experts there’s a lot of noisy disagreement over the details of what BDD is. There are so many blog posts out there about “doing BDD right”, “doing BDD wrong”, “BDD is not X”, “BDD is just Y”, “if you’re not doing Z you’re not doing BDD”, and so on. This sort of debate is a sign of a healthy and inquisitive expert community, but again it’s not helpful for getting people engaged in the basic principles and practices of BDD. It puts them off — “if these clever experts can’t even agree on what it is, what hope do I have?”. I like to think that if we set aside the fine-grained disagreements for a moment, we’ll be able to agree on some big fundamental stuff that would be useful right now to people who need help with their software development process.
You’re currently working on a book and screencast – How to Write a Web Application in Ruby. How did that come about? And when can we expect to see it!?
It’s adapted from a workshop I run for Ruby developers. In the workshop we incrementally build up a complete web application from scratch by reading the appropriate specifications and using only the Ruby standard library — TCPSocket, URI, CGI, that sort of thing. Then, once it’s working, we refactor it by replacing bits of our hand-rolled implementation with battled-tested third-party code like Rack, Active Record and Action Pack. So halfway through the workshop we have a long manual implementation of a web application, and by the end we have essentially a short single-file Rails app. People seem to get a lot out of the workshop when I run it, so the book and screencast are about taking that same content and making it available to anyone online.
The stated goal of the book is to help Rails developers to understand their tools better by illustrating what each piece does in isolation and how they fit together. Its unspoken ideological goal is to make the point that software isn’t magic and it doesn’t come about by a process of divine revelation. It’s just stuff made by people, and you’re a person, so you can make that stuff too. You don’t need to wait for someone else to come along and make a framework for you to use; you are capable of building a thing yourself. Of course there are good pragmatic reasons to reuse someone else’s work instead of building everything yourself, but ideologically it’s important to know that you have a choice. Software is brilliant and it should be empowering, not constraining.
I’m ashamed to say that it’s become a bit of a long-term project now, not because I’m not excited about it, but just because I’m a terrible procrastinator and I don’t have a publisher breathing down my neck about it, so I can easily put it on the shelf for months at a time while I’m working on other things. I first announced it on the Ruby Rogues podcast in August 2013 so it’s definitely been brewing for a while.
I’ve resolved to get it shipped this year. That sounds terribly pessimistic. What I mean is that I’ve made a resolution to speak at fewer conferences in 2015, because they ordinarily take up so much of my time, and the idea is that I’ll be freed up to get the book finished. It’s the main thing I’m working on right now. I just checked the PDF and it’s 77 pages so far. So it is real and it will be out before too long.
Your writing spans a pretty huge range of topics – not just technical (like this post from your website on the London Cycle Hire scheme). Where do you find your inspiration from?
I would love to say something motivational and high-minded here, but the truth is that my writing is mostly born of frustration. I am very excited about the possibilities presented by general-purpose computation, and that excitement turns to frustration when those possibilities go unrealised because of bad education or lazy design or whatever it is.
So much of what is wonderful and beautiful about the computable world is hidden under a thick layer of inane jargon, poor documentation, crummy explanations, arrogant behaviour, confusing interfaces and so on, and I feel compelled to try to dismantle those things whenever I see them. Often that amounts to just unproductive complaining, but sometimes it motivates me to try to build a really clear explanation of a particular idea, or at least a really clear illustration of why some existing thing is bad. That’s actually still just complaining but I invest some effort in dressing it up as something superficially more constructive.
Explaining things clearly, whether through human language or computer code or interaction design, is really difficult to do, but that’s what makes it important and worthwhile. I think that you can change someone’s life in a tiny way if you help them to understand something fundamental about the universe, so it’s worth putting a bit of effort into. In practice the main thing I’ve learned is that this is a terrible way to try to make a living.
Were you always going to be a developer? What do you think you’d be doing if you weren’t?
I was fortunate enough to have access to easily-programmable computers from a very young age, so yes, I’ve been programming for as long as I can remember, and it’s hard to imagine doing anything else for a living. I suppose that latterly I’ve been spending more time explaining things to humans than to computers, so under different circumstances maybe I’d have become a teacher. I am a huge fan of mathematics so it’s likely I’d have ended up as a maths teacher, if not an actual mathematician, if computers hadn’t existed. It’s a frightening thought.
Finally, and back to CukeUp; what are you looking forward to most at this years conference?
Well, obviously my bit is probably going to be amazing, but social convention dictates that I pick something else. Actually I’m really looking forward to the workshops, because workshops (more so than talks) are often an opportunity to really learn something new — to be that person who’s having their life changed in a tiny way. So I’m hoping to be shown different ways of thinking about Cucumber and BDD, and to get the chance to ask some awkward questions, and to find something new and interesting to complain about.
While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.
Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.
Dear next P.M.,
For an insight into Skills Matter’s 
The Skills Matter Blog 