Diamond recycling (and painting yourself into a corner)

The post I wrote recently on recycling tests in TDD got quite a few responses. I’m going to take this opportunity to respond to some of the points that got raised.
Do we really need to use the term “recycling”?
The TDD cycle as popularly taught includes the instruction to “write a failing test”. The point of my article was to observe that there are two ways to do that:

write a new test that fails
change an existing, passing test to make it fail

It’s this second approach that I’m calling “recycling”. Alistair Cockburn says that “it’s a mystery this should need a name” and it probably doesn’t. However, I’ve regularly seen novice TDD-ers get into a mess when making the current test pass causes other test(s) to fail. Their safety net is compromised and they have a few options, none of which seem very appealing:

Roll back to last green
Comment out the failing test(s)
Modify the failing test(s) to make them pass again

Whichever way you go to get out, you’ll want to try to avoid painting yourself into a similar corner in future.
Why do tests that used to pass start failing?
Ron Jeffries suggests that this will only happen if the tests don’t “say something universally true about the problem and solution.” Several people (including George Dinwiddie and Sandro Mancuso) demonstrated that this problem can be solved by writing a series of tests that each say something “universally true.” However, to me, this seems like a similar approach to that recommended by Alistair Cockburn in his “Thinking Before Programming” post.

I’m a big fan of thinking before programming. In the courses that I deliver, I routinely prevent students from touching the keyboard until they’ve thought their way around the problem. But, it’s just not realistic to expect that […]

By |December 9th, 2014|Agile, BDD, Cyber-Dojo, TDD, Uncategorized|3 Comments

Value by association

Do you care what label is on your shirt? Or your car? Or your laptop? I bet you do, but why? Is there something substantive underneath the fashion-victim facade or is it just some sort of post-modern tribalism?

A few of us have been debating the death (or otherwise) of agile, and it seems to come down to whether the agile brand has become devalued. I’d like to move the discussion back a decade or so and ask whether there was ever any value to the brand – value to the customer that is. (After all one of the principles in the manifesto states that “Our highest priority is to satisfy the customer.”)

I don’t believe that a customer derives any value from a consultant simply because they are ‘agile.’ I don’t believe in ‘value by association.’ I don’t trust brands.

If you want a plumber or lawyer do you seriously just look through the Yellow Pages (or contemporary equivalent)? Really? Don’t you ask friends and family for recommendations first? And if their recommendations are all busy won’t you look for referrals or reviews or some “independent” verification of someone’s suitability for taking your money?

I don’t even think a personal recommendation is enough. Competence needs to be qualified. A family lawyer is not necessarily the right person to use in a patent law suit. Someone who has successfully deployed agile in a small organisation is not qualified to deploy agile at the portfolio level in a multinational (thanks @tastapod).

As well as ‘competence’, we should take into account ‘attitude’ when we choose who to work with. I use ‘competence’ in the sense that someone has the knowledge, skill and experience requisite to perform the task that I need done. […]

By |October 4th, 2013|doa, Uncategorized|0 Comments

Chris Matts – an open letter

Welcome to another post in my “Death of agile” series. This post is an open letter to Chris Matts, the ‘father’ of Real Options and Feature Injection and co-parent of BDD.

See also:

Death of agile
Open letter to Dan North
Open letter to Gabriel Steinhardt

Dear Chris,

I recently came across one of your blog posts inspired by some of the vendors you met at Agile 2013 in Nashville. You were clearly outraged by the SAFE family of products that claim to ‘scale agile’ despite the absence of any convincing case studies, and from this you extrapolated the demise of agile.

I’d like to ask you to think again. No matter what sphere of human endeavour you look at, there have always been people gullible enough to buy snake oil, silver bullets or Spanish prisoners. And wherever there is demand there will always be those willing to satisfy that demand, unscrupulously if necessary.

When Harry Lime killed and crippled many Viennese with his sale of black market penicillin, did it to discredit the efficacy of that medication? I don’t think it was Graham Greene’s intent we reach that conclusion. Likewise, I don’t think that the marketing of unvalidated development methods discredits agile approaches or equates to the “death of agile.”

Agile is a set of values and principles that guide our approach to delivering value to our customers. It is as valid today as it was at the beginning of the millennia and I believe that this is no time to start lamenting.


By |September 25th, 2013|Uncategorized|0 Comments

Introducing 2nd party

It’s always a good idea to wrap any component that we don’t own behind an interface that we do own. There are a number of benefits:

1) We can tailor/narrow the interface to expose only the behaviour that we need
2) When we choose to change the external component, we’ll only have to modify the facade code behind our interface (as long as the interface isn’t leaky)
3) We can maintain our own suite of acceptance tests that run against the external component through our wrapper to ensure that it provides the behaviour we expect. New versions of the external component should be verified using this suite before they are accepted.

So far, so good. The confusion creeps in with the definition of ownership. 3rd party code is provided by some other organisation – you don’t own it. Components developed and maintained by other teams within your own organisation don’t fit into the 3rd party category. However, if you need to speak to another team or another department to get a change made to a component, then you clearly don’t own it. Our colleagues down the hall may work for the same company as us, but that might make it even harder to get bug fixes or change requests approved.

I was working with recently with a large european client, where someone told me that they call this sort of code 2nd party. I liked it so much, I bought him a cupcake.

By |June 23rd, 2013|Uncategorized|1 Comment

Rejecting CDD

One of the 12 agile principles is:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

Indefinitely. Wow, that’s a long time!* How will we ever know if we’ve delivered on this principle? Well, we won’t. We’ll only know when we fail to deliver – when team members burn out. When it’s too late.

So, take a look a yourself and your team. How important is that first coffee in the morning? Or the second? Agilista, meet barista.

The first step in treating any addiction is to admit that it exists. You don’t need that caffeine. Remember the manifesto – agile processes promote sustainable pace.

Practice what you preach and say “No” to Caffeine Driven Development.

* With thanks to Douglas Adams: “Space is big. Really big. You just won’t believe how vastly, hugely, mindbogglingly big it is. I mean, you may think it’s a long way down the road to the chemist’s, but that’s just peanuts to space, listen…”

By |June 18th, 2013|Uncategorized|2 Comments

Be pure. Be vigilant. Behave.

There has been a bit of traffic on the Growing Object Oriented Software (GOOS) mailing list recently about how many tests you should write, and what sort they should be. Understandably it got back to the perennial discussion about what constitutes a unit test, what an integration test, what an acceptance test. And where does the testing pyramid fit into all this?

All important questions and yet somehow ephemeral in their unfathomability.

Torbjörn Kalin got to the heart of the matter with his concise response:

“What is the purpose of the test? What is it that we want to test? How do we test it?”

It doesn’t matter what you call it. The label is incidental. Turn to the rubber duck on top of your monitor and earnestly ask:

“What is it that I am worried might fail?”

If you don’t answer the question honestly, then Torquemada might just come a calling.


By |May 16th, 2013|Uncategorized|2 Comments

Simpler. Clearer. Faster.

The UK Government has invested £17 million over the past 2 years migrating from several rather old websites to the new, shiny gov.uk website. James Stewart and Anna Shipman gave an uplifting talk at the Edinburgh BCS branch meeting on May 1st, describing how they had scaled from one small team of 12 to ten teams (and an organisation of over 200) in not much more than a year. Not only that, but they had delivered on-time and have since gone on to win the “Design Award of the Year.” Everything was not perfect – they admit to having worked unsustainable hours and of accruing significant technical debt – yet they appeared energised, motivated and undeniably happy.

Prior to that meeting I spent several days with a large corporate client where a large number of teams were being mobilised to develop a major, strategic implementation. They will have to learn new technologies and new methodologies at the same time as being asked to deliver mission critical functionality within a very tight schedule. These teams are in their early days, but there are early signs of the pain to come.

Both of these teams consider themselves to be agile. Neither of these teams consider themselves to be using behaviour driven development (BDD).

My corporate client is aiming to deliver a complex, monolithic application, and has a small number of product owners supported by a somewhat larger number of subject matter experts (SMEs). There is conceptually one backlog, but each team is having a subset of it pushed onto a team backlog from which they pull stories to be elaborated. There’s no clear division between each team’s role and hence each story may require the team to interact with different […]

By |May 3rd, 2013|Uncategorized|0 Comments

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

Edinburgh BDD Kickstart

At the beginning of March Matt Wynne and I ran another very enjoyable 3-day BDD Kickstart course in Edinburgh. The course was hosted in the Edinburgh Training and Conference Centre in the heart of the old town which, despite its historical location, is a thoroughly modern venue.

There’s a lot to cover in the three days, so we’re careful to ensure that everyone remains suitably snacked and caffeinated throughout the day. And when you’re learning intensively it’s crucial to move around and take regular breaks, so we  decided not to have lunch inside the training venue, but at local restaurants. Forcing everyone to go outside at lunchtime was a bit risky because the weather in Edinburgh has been particularly aggressive this year, but we all survived unscathed.

All 7 delegates enrolled for the full course (rather than opting for the 1-day BDD Fundamentals or 2-day BDD Applied modules). This gave us plenty of opportunity to get to know each other, especially since we regularly swapped teams and pairs while working through the practical exercises. Having both Matt and I there for the training also meant that there was plenty of time to focus on the specific questions and concerns of each delegate.

Both Matt and I live in Scotland, so the original motivation to run BDD Kickstart in Edinburgh was to try and make it more practical for local practitioners to attend. It surprised us that most delegates weren’t from Edinburgh, or even Scotland. Three flew up from the south coast of England, two came from north-east England, and one was from Canada (though he didn’t fly over just for the course). We also had a great mix of disciplines with testers, developers and project managers all represented […]

By |March 31st, 2013|Uncategorized|0 Comments