Monthly Archives: April 2013


On alcoholism, chainsaws and deliberate practice

I’ve been running a lot of training courses recently and I’ve noticed that once people have chosen where they’re going to sit, they return to that position every day. We are creatures of habit, and some habits seem to form very quickly. If I rearrange the room before the second day, or ask people to change places, no-one seems particularly bothered – they simply go and find another seat. So, having a fixed seating position seems to be a habit that’s easy to slip into, yet easy enough to break.

Other habits are harder to shift. We’ve all probably tried to modify our behaviour using rational thought and wishful thinking. For short periods of time it can even look like we’ve succeeded, but then some stimulus knocks us off course and we revert to our previous behaviour. It’s for this reason (I guess) that members of Alcoholics Anonymous always consider themselves “alcoholics that haven’t had a drink for <some time>” where <some time> can range from hours to years. Avoiding your old behaviour is certainly the first challenge. The next, and harder, challenge is becoming comfortable with your new behaviour. This is as true for our work habits as it is for any others.

The habit that I see many teams having trouble breaking, is the habit of forgetting their quality aspirations when they come under pressure. As deadlines loom I often hear people talking about “adding the tests later” or doing something “just for now”. A lot has been said about technical debt (see Martin Fowler’s excellent post or my contribution to “97 Things Every Programmer Should Know”), but I think many of these habitual, time-driven responses can’t really be considered technical debt. They’re more like […]

By |April 26th, 2013|Uncategorized|0 Comments

Living documentation can be readable and fast

In an earlier blog I promised to describe how we could exercise thin slices of our application stack, while still expressing our scenarios in a business-readable, end-to-end style. I talked about this at Cuke Up! last week and published an article covering it in the ACCU journal Overload. For completeness, I’m now adding this as a blog entry too.

Let’s assume we have the example scenario below, taken from Matt Wynne’s Squeaker example, that deals with registering at some website. (This is written in Gherkin and will be executed by Cucumber.)
Feature: Sign Up
Scenario: New user redirected to their own page
  When I sign up for a new account
  Then I should be taken to my feeds page
  And I should see a greeting message
Each line in the scenario causes a corresponding ‘step definition’ to be executed. How you implement the step definitions is up to you, and depends on the nature of your system. The example above might:

fire up a browser, navigate to the relevant URL, enter specific data, click the submit button and check the contents of the page that the browser is redirected to
call a method on a Registration object and check that the expected event is fired, with the correct textual payload
or anything else that make sense (e.g. using smart card authentication or retina scanning)

The point is that the text in the example describes the behaviour, while the step definitions (the glue code) specify how to exercise the system. An example glue method would be:
@When(“I sign up for a new account”)
public void I_sign_up_for_new_account() {
// Do whatever it takes to sign up for a new account
// e.g. exercise the web UI using Selenium WebDriver
Newcomers to this style of working often adopt […]

By |April 6th, 2013|Uncategorized|6 Comments