CukeUp

While It’s Compiling: Skills Matter interviews Tom Stuart

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.

CukeUp! 2015: Call for Papers

cukeup_2015cfp

After a sold out 2014 conference, CukeUp! returns to London for its fourth iteration. The conference brings together all stakeholders who use BDD for two days of talks and workshops, helping teams to crack complex software problems. We’re on the look out for talks that will inspire and educate others around BDD and it’s wider practices – so if your team is just starting out on the road to BDD, you’ve got some nifty tips to test the untestable or you’ve got a use case on how to bring technical and non technical teams closer together – we want to hear from you.

We are planning for talks to last around 30 minutes, so keep introductions to a minimum and allow time for questions!

To submit an idea for a talk head over to the Call For Papers page. We’re especially keen to hear from people who haven’t spoken at conferences before. If you are worried about presenting alone, feel free to pair with someone on your team. The CukeUp community is very friendly and this is a safe way to dip your toes in the public speaking arena. If you need some help a great place to start is here.

If you have any questions then please contact us at cukeup@skillsmatter.com.

The CfP will close on January 23rd. All presenters will be contacted the week commencing February 2nd.

Please be sure to read the Skills Matter Code of Conduct. It outlines what we expect from our speakers and guests so that we can continue to provide a fantastic environment to learn and share skills for everyone.

While It’s Compiling: Skills Matter interviews Mary Thorn

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.

mary-thorn-interview-cukeup

Mary Thorn is a Director of QA at ChannelAdvisor in Morrisville, North Carolina, and she has a broad testing background that spans automation, data warehouses, and web-based systems in a wide variety of technologies and testing techniques.

We caught up with Mary ahead of her talk at CukeUp! New York City on the 30th September.


In your talk at the upcoming CukeUp! Conference in New York you’ll be looking at the promises of Behaviour-Driven Development (BDD) and Acceptance Test Driven Development (ATDD), namely, greater collaboration between Product Owner & team and focus, along with an increase in the value produced. Without giving too much away, can you give us a quick insight into how you see this working?

I feel that “How to implement BDD?” is the million dollar question. I’ve been successful on four projects and, even though I feel I have a lot more to learn, I want to share my experiences of what’s been successful. BDD can be implemented in Waterfall and Agile processes, with or without automated testing. My experiences have all been in an Agile process with automated testing to back it up, although I have examples from my current job of Waterfall projects who have implemented BDD without automated testing.

The first step in the process for me has been selecting which automation tool to use. Next, I start to introduce the topic of BDD by either a lunch-and-learn or community of practice event. The goal of this step is to start to explain the practice and benefits. My hope is that someone in the room will help me champion this process. A lot of times, the QA team reporting to me are yearning for more collaboration and to be involved in requirements definition, so it is not a hard sell. The biggest pushback typically come from the Product Owners and Business Analysts because they feel that we are adding more work to their plate. In reality we are not, we are adding more upfront work, but less work and rework later in the process.

Next I start to partner and build relationships with the Product Owners, Business Analysts, Functional Analysts, Scrum Master and Development Manager. I encourage them to engage in what we can do as a team to build a better product and make the clients happy. I also start to plant seeds with the QA team to bring up BDD as a retrospective item for the team to try. The next step is running a BDD workshop for the team. Once everyone is trained after the workshop, I encourage the POs or BAs to take just one or two stories out of the next sprint and to take a stab at writing the Gherkins.

After having one-to-two stories with feature files in hand, the PO will hold a grooming session with the entire team (including, PO, Dev and QA) to discuss. The PO will introduce the user story,the GOAL they are trying to accomplish, the acceptance criteria, and the scenarios. Most of the time the scenarios will be 75% of the conversation. During the discussion you will add, remove, and refine the examples as you discuss. At this point the “Whole Team” now owns the feature files and examples, not just the PO or QA. Once everyone agrees on the scope, the team will then estimate the size of the story in points.

Next is sprint planning with the Whole Team. I ask the team to bring the feature files as well as the User Stories to help when breaking stories into tasks. I have found by doing this, estimates are smaller and more accurate as most examples are covered.

Once the sprint starts, Dev and QA review the feature file together one last time to make sure it’s complete. Any additional scenarios at this time should also be reviewed with the whole team. Then developers use TDD to code the scenarios in the feature file. Due to the fact the developers already have the tests from the examples and scenarios they can go ahead and write their equivalent unit tests. The QA automation engineer can start developing in parallel as long as they have discussed with the developer the things that the developer needs to do to make that story “automatable”. The goal is that Dev and QA finish at the same time and that, when all the tests “Go Green”, then the PO can accept that the story is “Done” because all the scenarios and examples pass.

After doing this for almost 3 years now, I’ve seen these benefits:

  • Expectations, Goals and Business Value are communicated and challenged and clarified with every story
  • Defined Scope
  • Overlooked Requirements Revealed
  • Tangible Reference Materials
  • Accurate Story and Task Estimations
  • Deliberate Collaboration Between QA/DEV/PO
  • Increased Productivity
  • Decreased Bugs from SIT/UAT/PROD
  • Commitments are met (and often times exceeded!)

With that in mind, what are the main factors that can pose a threat to getting BDD right? Are there any classic pitfalls you see recurring again and again?

My main pitfall I run into time and time again is that the Product Owners don’t think it is their responsibility to write their acceptance criteria in acceptance test format. This role is solely the QA’s responsibility and that it is just putting additional work on their plate. What they don’t understand at the beginning is that the discussion helps to uncover missing requirements and helps the team build it right the first time. I eventually get there, but it’s a pitfall that happens over and over again.

Eric Evans, who coined the phrase ‘Domain-Driven Design’, is speaking as well this year. What do you think are the main connecting threads between DDD and BDD?

I have not worked on a project yet where the DDD concept was used. However, I have kept up with the community and I think I understand the concepts. I still think these two concepts (BDD and DDD) have the same goal which is “creating conversations so that you build the right thing the customer wants the first time”. These are just two different ways to meet that goal.

This isn’t the first time you’ve spoken at CukeUp!, and we’re delighted to have you back after your talk last year. As the conference is built to be as much a social event as a series of talks, during your experience last year were there any conversations you had with speakers and delegates which have shaped your work or ideas over the past year?

They have! I am super excited about the Cucumber Pro tool that is coming out. This is a much needed feature in our open source community and one that I have yearned for the past four years working with Cucumber. I currently have left the company I worked at last year who used Cucumber and now I use it’s sister tool Specflow and I hope I can convince Aslak [Hellesøy] to integrate with it in the future. I might have to request a name change though 🙂

And obviously, you’re returning to a CukeUp! that’s slightly different from last year with the addition of two half-day workshops exploring non-technical applications of BDD. Do you feel there is a wider need for non-technical solutions in BDD at the moment? Essentially, do you feel that automation runs the risk of degrading or avoiding regular and constant communication

Great question, and one that I am all to familiar with. Both companies that I came into that had implemented Cucumber before I got there said they were BDD shops and really were just using it for automation purposes. This tool is great for automation but even better for communication and I do feel we are running a risk of avoiding regular and constant communication. However if implemented correctly, you can put in process steps that avoid this and I hope to discuss that in my talk.

London is blessed with a variety of conferences and meet-ups that support the BDD community. You’re based in North Carolina, is there a strong ‘after-hours’ software community there?

There absolutely is. The ‘Research Triangle Park’ area is one of the fastest growing cities in the US for IT jobs. We have several Agile Meetup groups and Agile Testing and Automation groups. This year I co-chaired our Bi-Annual TISQA testing conference, as well as our first Agile conference, TriAgile.


CukeUp! New York City

Mary will be speaking at this years’ CukeUp! conference Tue, 30th Sep – Wed, 1st Oct at DUMBO Loft, New York City.

She will be joined by a host of leading names from the world of Cucumber including Aslak Hellesøy (creator of Cucumber & co-founder of Cucumber Ltd.), Eric Evans, George Dinwiddie, Paul Rayner and many more!

This two day conference will explore various aspects of BDD in this New York community event. CukeUp! is organised and curated in partnership with Cucumber Limited and also runs annually in London.

Click here to book your ticket now!

While It’s Compiling: Skills Matter interviews George Dinwiddie

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.

george-dinwiddie

George Dinwiddie is a software development consultant and coach with over thirty years of experience, and a speaker at this year’s CukeUp! in New York City.

We recently got the opportunity to ask George about the relationships of Behaviour Driven Development (BDD) to Test Driven Development (TDD), the importance of conversation in BDD and his upcoming session at CukeUp! 2014.


It seems that for many developers BDD is often seen as an alternative to TDD. Do you think that’s a correct assumption, or are BDD and TDD linked and dependent on each other?

These terms are not very precise, and have different interpretations. When Kent Beck invented TDD, he was doing it at the programmer level. Josh Kerievsky (I believe) coined the term Story Test Driven Development, for writing tests at the acceptance level for a user story. Others have called this Acceptance Test Driven Development. In some ways, BDD encompasses all of these, though the emphasis at the programmer level is often on the interactions between objects, rather than on the state of an object after an interaction.

Is BDD essential for effective teamwork and software creation or is there an alternative? Essentially, why should teams choose BDD?

Certainly people have been building effective teams and creating software long before BDD came along. BDD is a convenience, and a power tool to make development more effective. BDD describes the desired functionality with more precision than the typical requirements document. BDD promotes a discussion that’s equally accessible to the development team and the business asking for development. And BDD creates a safety net of regression tests that alerts us when we’ve violated a prior expectation.

You have 30 years of experience in software development and coaching – what have you learned in that time that you wish you knew from the beginning?

I wish I’d known that software (and hardware) development is not just a technical problem. It should have been obvious to me, since my undergraduate degree is in English with a Psychology minor, but I didn’t notice. I spent many years focusing all my efforts on the technical side of things, and losing years of opportunity honing my people skills. Both are important, but only very small projects get accomplished without collaborating with other people.

Back in April at CukeUp! in London, Elizabeth Keogh discussed some of the big things that have gone wrong over the past 10 years, specifically that BDD is not right for everyone, that a focus on automation can actually slow people down (too many scenarios, not enough conversations or conversations less about behaviour and more about how language should be phrased); she surmised that the conversations were the single biggest aspect of BDD. Would you agree with that conclusion?

I do believe that the conversations are the core aspect. Alistair Cockburn has said that the speed of software development is the speed of transferring an idea from one brain to another. Conversations with examples are perhaps the fastest way of doing this. I don’t exactly agree that BDD is not right for everyone (though they’re welcome to forgo it if they want). I do agree that the focus should be on the conversation, and the automation should support that. Not everything needs to be automated, and on a large project, you’ll never have time to automate every interesting scenario. One of the things to talk about are which scenarios seem worth running repeatedly and which ones are likely to detect problems that won’t easily show up elsewhere.

Your talk at the upcoming CukeUp! in NYC is focussed a lot on visualising scenarios in order to show clear understanding of what we or others should expect in the future. Can you give us a brief insight into this visualisation?

When we describe the behavior we expect our program to exhibit, we need to be specific enough that others understand our meaning. So often we, as people, are a bit vague in our conversation. If those we’re talking with share enough of our implicit assumptions and knowledge, they often understand what we mean. If not, they can ask. When we write this down, the reader is shifted in time from the writer, and it’s generally not possible to ask for clarification.

This leads us to expect more details. But which details? If we write every detail we can imagine, we obscure the intent, and the reader is not helped. Worse, we lead them astray, as they may think certain details are essential though we just mentioned them as an example. Writing scenarios is as much an art form as writing software. It takes work and attention to detail and correctness.

The aim of CukeUp! is not just for developers, but rather encompasses product owners, testers, business analysts and so on. How does your session address all of these stakeholders?

All of these stakeholders need to understand the scenarios, and ensure that their concerns are adequately covered in them. That’s why I recommend the “Three Amigos” approach to writing the scenarios. This approach writes them collaboratively with all the necessary points of view participating. With collaboration, they can spot when jargon from one stakeholder makes it unclear to others, or an example offered by one is too narrowly focused. Writing good scenarios is hard, and when it’s done from only one point of view, it usually misses the mark.


CukeUp! New York City

George will be speaking at this years’ CukeUp! conference Tue, 30th Sep – Wed, 1st Oct at DUMBO Loft, New York City.

He will be joined by a host of leading names from the world of Cucumber including Aslak Hellesøy (creator of Cucumber & co-founder of Cucumber Ltd.), Eric Evans, Mary Thorn, Paul Rayner and many more!

This two day conference will explore various aspects of BDD in this New York community event. CukeUp! is organised and curated in partnership with Cucumber Limited and also runs annually in London.

Click here to book your ticket now!

Friday Round-Up: 31 March – 4 April

CukeUp! 2014, Skills Matter, London

Software Developers London kicked off Monday, when they came along to Skills Matter HQ to discuss the latest in the world of social technology. They were joined by multiple speakers who ran through platforms such as Facebook, Twitter and Google to share where things are headings and what to expect next.

On Tuesday, the Penatho User Group demonstrated how Pentaho can be used in multiple areas, such as Geo-informatic visualisation. Nelson Sousa, Dan Keely and Owen Bowden shared past experiences using Pentaho and how it can be applied in the real world.

The London Clojurians joined us to talk about the benefits of Static Typing. Ambrose Bonnaire-Sergeant ran through its uses and its benefits which make it perfect when adding it to Clojure.

Austin Bingham and Robert Smallshire brought in a crowd for their talk on Domain-Drive Design with Python. They both explored when and how dynamic language solutions are most appropriate for domain models discussing the trade-offs between flexibility, maintainability and performance. The talks were illustrated with experiences drawn from building industrial domain models in Python in the energy sector to support high performance computing applications.

London Titanium discussed, in detail, Node.ACS & JSON, how to use as well as apply them. Two interesting talks delivered by Ketan Majmudar and Martin Hudson, both true experts, helping delegates iron out any problems they might face and how to overcome them.

CukeUp! 2014

We finished of the week with our second conference of the year – CukeUp! This year, more people than ever before joined us with our amazing partners Cucumber Limited at Skills Matter HQ for two days packed full of talks, presentations and – for the first time – a full day of hands-on sessions led by the best in the world of Cucumber.

If you missed it, fear not! You can catch all the Skillscasts (film/code/slides) here. You can also see the pictures from the two days on our Flickr set.

And finally, a huge thank you to our sponsors – Sopra, Inviqa and Specflow!