BDD Kickstart: London and 2013 plans

BDD Kickstart is dead. Long live...

We are coming up to the one year anniversary of the first public BDD Kickstart, and we’ve got some news…

Matt and I have enjoyed running BDD Kickstart over the last year or so. We’ve had hundreds of people go through the course in all, with courses run for the public and privately in-house.

Over the year we’ve grown a team of real expert practitioners who also happen to be fantastic at teaching and mentoring. Seb, Rob, Julien and Steve have been partnering with us to help us run many more courses than we could have done on our own. With Suzan publicising and marketing the courses, we have built up some great momentum: enough to expand our course lineup.

BDD Kickstart’s fundamental philosophy has always been to put you in a room with experts. With the addition of new partners, we’re growing the range of subjects we can offer at that very high quality level. We can offer courses in more than just BDD. So we needed a new name.

Introducing…

Quality matters to us enormously, so we’re growing slowly. We’re focusing on running our existing Continuous Delivery course, and we’re already running in-house Ruby courses. We’re writing a “Hexagonal” course to teach pure OO design principles for modern web applications.

We’d like your feedback please!

We’re actively seeking feedback to help guide us as we grow and expand. Your emails are always welcome, but we’d especially like to speak to you on the phone if:

• You have been on a course with us and you have some feedback or a testimonial
• You’ve been thinking about coming along but haven’t done so yet for specific reasons (location, can’t spare the time, financial, etc)
• You have an idea of a subject you’d like to learn from us that we don’t offer yet

Send us an email with your phone number or Skype handle and we’ll set up a call.

What’s next

We have two public courses available at the moment: we’re teaching our popular BDD Kickstart course in London in December and our Continuous Delivery course in Paris in March. If you’re interested in either of these courses, you can sign up for London now, or email us to express your interest in the Paris course.

It’s an exciting time for Kickstart Academy: we look forward to seeing you at one of our workshops soon!

How to write a great story

Second in my mini-series of Cucumber videos: a quick introduction on writing a great story.

Note: This approach works best when starting off a brand new feature in the system. When changing existing features, we need to work to keep our preamble up to date. Matt Wynne's blog post shows you how.

If you like what you see, and you'd like to learn more, a quick reminder that Matt and I are running BDD Kickstart in London this coming December: the early bird ends November 4th.

The simplest Cucumber project ever

Cucumber can be really very simple. Here’s a short video to show how you can get started in two minutes flat, using only two files: a simple feature file, and a few lines of ruby to execute it.

If you like what you see, and you'd like to learn more, a quick reminder that Matt Wynne and I are running BDD Kickstart in London this coming December: the early bird ends November 4th.

Kickstart your team on BDD

Matt Wynne and I have been running courses on BDD for the BBC Future Media division for the past year or two. They’ve been extremely well received, so we’ve decided to open them up to the wider public so everyone can benefit.

The full details are at bddkickstart.com, but read on for a bit more info:

When/where is it?

There are four seperate day-long workshops running in October, from 8th - 11th in Central London near Trafalgar Square. You can just come to one day, or all four.

What’s the course material?

Day 1 is entitled “Just enough Ruby”. It teaches programmers from other languages the basics of Ruby so that they are comfortable using cucumber effectively.

Day 2 is a BDD workshop for the whole team. It builds awareness and enthusiasm for the concepts with a chance to practice collaboration in the way that makes BDD work.

Day 3 is a practical day for programmers to learn about Cucumber: what it is, what it isn’t, and how to write good cucumber code that can be maintained over time.

Day 4 covers advanced BDD concepts and common pitfall people find when using these techniques in the real world.

Do I have to sign up for all four days?

No, you can pick and choose, and just come to one day if you like. There’s a small per day discount if you book all four days.

So which days are for me?

if you're a developer with Ruby experience, you might want to skip the first day and come along to days 2, 3 or 4.

If you are a Product Owner, Business Analyst, Project Manager or UX specialist, come along to just day 2, and understand why BDD is designed for you guys in the first place!

If you're a keen developer but not necessily very experienced in Ruby, you should consider the full four day course. We'll take you through the basics of Ruby, the reasons behind doing development this way, how to use Cucumber properly (saving you time in the long run) and some neat advanced tricks.

Are you running early bird tickets, or promotions?

Glad you asked: if you use the code super-early-birdy you’ll get 20% of the list price until 1st August, just for reading this far down the page :)

How can I find out more or book my place?

You can find more info and book at bddkickstart.com, or send us mail if you have specific questions.

Hope to see you in October!

Extreme YAGNI: How BDD nails your prototyping stage

Sometimes people don’t see the value in the BDD process. They contend that the BDD ceremonies are a waste of time, and get in the way of delivering real features to customers. Others cannot see how to apply BDD to their project, as no-one knowns exactly what the project will look like yet. As they’re only in the prototyping stage, by the time a feature file is written and made executable, it’s already out of date.

I don’t agree with this. If our process is set up right, we can prototype using just as effectively and retain the collaboration benefits that BDD gives us.

You Ain’t Gonna Need It

One of the biggest wins that Test-driven Development (TDD) gives us is the principle of YAGNI - “You Ain’t Gonna Need It”. It’s very tempting when writing code to go off on a tangent and produce a beautiful structured work of art that has zero practical use. TDD stops us doing this by forcing us only to write code that a test requires. Even some experts who don’t practice or encourage TDD often espouse the power of writing the calling code first in order to achieve much the same effect.

BDD gives us the same YAGNI win: but at a level higher than TDD. With the BDD cycle we’re adding thin slices of customer observable behaviour to our systems. If we can only write the code thats directly used by the business, then in theory we should be cutting down on wasteful development time.

However, there’s a snag here. if we’re prototyping, we don’t know whether this feature will make it into the final product. We still need to give feedback to our product team, so we need to build something. If the feature is complex, it might take a while to build it, and the feature might never get used. Why bother going through the process of specifying the feature using BDD and Cucumber features?

Happily, we can take YAGNI a level further to help us out.

Extreme YAGNI

Often in TDD, and especially when teaching it, I will encourage people to take shortcuts that might seem silly in their production code. For example, when writing a simple supermarket checkout class in Javascript, we might start with a test like this:

    var checkout = new Checkout();
    expect(checkout.total()).toEqual(0);

Our test defines our supermarket checkout to have a total of zero on creation. One simple way to make this work would be to define the following class:

    var Checkout = function() {
      this.total = function() {
        return 0;
      };
    }

You might think that’s cheating, and many people define a member variable for total, set it to 0 in the constructor, and miss this step out entirely. There is however an important principle at stake here. The code we have does exactly what the test requires it too. We may not need a local variable to store total at all.

Here’s the secret: we can practice this “extreme YAGNI” at the level of our features, too. If there’s a quick way to make our feature files work, then there’s nothing to stop us taking as many shortcuts as we can to get things working quickly.

For example, if we’re testing the user interface of our system via Cucumber features, one fast way to ensure things are working is to hard code the values in the user interface and not implement the back end behaviour too early. Why not make key pages static in your application, or hard code a few cases so your business gets the rough idea?

Again, you might think that’s cheating, but your features pass, so you’ve delivered what’s been asked for. You’ve spent the time thrashing out the story in a 3 amigos meeting, so you gain the benefits of deliberately discovering your software. You’re giving your colleagues real insight to guide the next set of stories, rather than vague guessing up front. Our UX and design colleagues now have important feedback through a working deployed system very quickly, and quick feedback through working software is a core component of the agile manifesto.

By putting off implementing the whole feature until later, we can use BDD to help us navigate the “chaotic” Cynefin space rather than just the “complicated” space. This in theory makes BDD twice as useful to our business.

Fast, fluid BDD

This all assumes that we have a fast, fluid BDD process, with close collaboration built in. If it takes a week to coordinate everyone for the next feature file, then the temptation is to have a long meeting and go through too many features, without a chance to pause, prototype, deliver and learn from working software. Maybe it’s time to re-organise those desks and sit all the members of your team together, or clean up your remote working practices, or block out time each day for 3 amigo sessions. You’ll be suprised how much small changes speed your team up.