Coding Is Like Cooking

At agile2008 I attended a session with Dan North about Behaviour Driven Development. Someone on the agile sweden mailing list was asking about it, so I decided to write up my notes here.

Most cellphone and computer software is delivered late and over budget. The biggest contributing factor to cost bloat is building the wrong thing. So what software and business people need is “a shared understanding of what done looks like”.

Test Driven Development is about design, conversations, and writing examples for a system that doesn’t yet exist. It’s not really about testing. However, once the system exists, your examples turn into tests, as a rather useful side effect.

A User Story is a promise of a conversation, and it is in that conversation that things go wrong. The customer and developer rarely agree what “enough” and “done” look like, which leads to over- or under- engineering.

Dan suggests a format for User Story cards which aims to prevent this communication gap.

On the front of the User Story index card, you have the title and narrative. The narrative consists of a sentence in this format:

As a stakeholder
I want feature
so that benefit

where benefit is something of value to stakeholder.

On the back of the card, you have a table with three columns

Given this context | When I do this | then this happens

Then you have 4 or 5 rows in the table, each detailing a scenario. (If you need more than that then the story is too big and should be split)

Dan finds that in his work, this leads to conversations about User Stories where “done” and “enough” are discussed, and defined.

User Stories should be about activities, not features. In order to check that your User Story is an activity, you should be able to do a thought experiment where you implement the story as a task to be performed by people on rollerblades with paper. You must think about it as a business process, not a piece of software.

When creating the story cards, the whole team should be involved, but it is primarily the business/end user stakeholders and business analysts who write the title and narrative on the cards. They then take in a tester to help them to write the scenarios.

Are people familiar with the V model of software testing? When this was conceived, they thought that the whole process would take 2 years, and span the whole project. Dan ususally does it in 2 days. Many times for each project.

Then Dan offered to show us how to do BDD using plain JUnit. He requested a pair from the audience, so I volunteered. At this point my notes dry up, and I am working from memory, but I think the general idea is like this.

You talk about “behaviour specs” not tests. The words you use influence the way you think, and “behaviour specification” gives much better associations than “tests”.

Each behaviour specification should be named to indicate the behavour it is specifying. Not “testCustomerAccountEmpty” rather “customerAccountShouldBeEmpty”.

In the body of the spec, you can start out by typing in the prose of one of the scenarios you have on the user story, as a comment.

//given we have a flimble containing a schmooz
// when we request the next available frooble
// then we are given a half baked frooble and the schmooz.

Then you can fill in code after the “given” comment. When you have code that does what the comment says, delete the comment. Repeat with the “when” and “then” comments.

In this way, you build up a behaviour specification that drives your development of the system. A few minutes later (hopefully) you have a system which implements the specification, and at that point your spec helpfully turns magically into a regression test which you can run. At that point you can start calling it a test if you like. But actually it is more helpful to your brain to continue to think of it as a behaviour specification. It leads to much more constructive conversations about the system.

The project manager was obviously a little irritated. “By this stage of the pre-study, we really should have the requirements a little more nailed down than this. That’s two new requirements since last week. Or what does everyone think?” he looks around the table, expecting support. The business representative looks disappointed and hangs his head.

Without really thinking, I follow my instinct and jump in. “It seems wrong to me to say to the customer that he can’t have any more features at this stage. Perhaps he should be prepared to drop something else instead, but surely we should be prepared to respond to the needs of the business? We are still in the pre-study, after all”

The project manager was not impressed. “This pre-study has already been going on for nearly 2 months, we really need to put together a budget and project plan so we can pass the next tollgate and proceed to the implementation phase.” He looked around the table sternly, then his frown softened a little. “Well ok, you can have these two new requirements. Let’s take a look at them”

A few days later, the project manager called me into his office.
– “You can’t go telling the customer he’s allowed to change his mind. After that meeting he came to me with more requirements. Your comments confused him as to how our software development process works. Please don’t do it again”.
– “But I though we were trying to be agile in this project? You know, short release cycles, end of iteration demos, like in Scrum”.
– “Yes, we are following a process which is more agile than the standard company mandated process. We have got permission to skip two of the tollgates, and 5% extra in the budget for ‘adjustments’ so we can respond to the customer feedback we get at each demo. We are not doing Scrum though. Who told you that?”

Sigh. I heard “agile”. What I should have heard was “more agile than the standard company process”.

Michelle the manager has two small children. She regularly puts in a 45 hour week. Alan the project manager also has two small children. He officially works 80%. The first architect, Steve, has one small child. He officially works 90%. The second architect, Flo, has two small children. She officially works 100%. Also on the project team are a number of developers, testers and other experts.

The project isn’t doing so well, and when there are about 6 weeks left until the delivery deadline, Alan the project manager starts coming in on Fridays – the day he usually spends at home with his children. Luckily his wife’s mother lives just round the corner, and since she is retired there is no problem with childcare.

A short time later, he starts to make impassioned speeches to the project team about how important it is to make the deadline, and presents a strong case that overtime is needed. He asks everyone has to email him with their availability over the coming two weekends.

Michelle already works weekends semi-regularly. Her husband is in a business that is suffering from the recession, so he is only working 75% anyway, so there is no problem with childcare. She is available.

Steve is hardworking and ambitious, and his wife is happy to spend more time looking after their child. Steve is available.

One of the developers, Paul, has one small child, but his wife’s mother is also keen to help, so childcare is not a problem. He is available.

None of the other developers have children. No problem with their availability then.

The thing is, Flo does have a problem. She has no extended family within reach who could be called in at such short notice. Her husband is already at home on paternity leave 100% and is finding it tough. He doesn’t want to take up the slack, and she doesn’t want to spend any less time with her children than she does already. After some thought, Flo tells Alan she is not available.

So what happens? Everyone works extra, except Flo. Alan is frustrated because he feels he can’t give her any important tasks to work on, because he knows she won’t stay late to finish them. Then Flo requests to work 80% in the new year, so she can spend more time with her children. (By Swedish law, all parents with young children who have a full time job have the right to reduce their hours.) Alan is not pleased, and talks to his boss about the situation. The project must go out on time, and he feels Flo’s behaviour is endangering this. The upshot is that Flo is told her contract will not be renewed.

The official reason given is that “working 80% is not compatible with the rate of productivity we require of an architect at this workplace”. The secondary reason given is the unwillingness to work overtime. As a contractor and not an employee, Flo has no recourse, the law doesn’t apply, and she is left searching for a new contract to work on.

It turns out that even in enlightened, feminist Sweden (1), even when the boss in question himself has small children and normally works 80%, even when the other architect in the team officially work less than 100%, it is still the case that a mother working the hours specified in her contract, is not able to keep her position.

If this is what it is like in Sweden, God help working women in the rest of the world.

(1) Just as an example how the feminist culture affects the political agenda: The main opposition party, (who polls indicate will win power at the next election), wants to quota parental leave so that each parent will be forced to take half of time available. This must be the only nation in the world that expects fathers to stay home from work for 8 months with each of their children.

If you were looking to employ someone, what would you say to a candidate like this:

• highly intelligent, excellent qualifications for the job, 10 years relevant experience, hardworking, ambitious.

Sounds good, doesn’t it? What if she then added:

• has 2 children, will not work overtime, (although still hardworking during normal working hours)

Perhaps not quite as interesting?

Then if she went on to ask to work 80%?

So the reality is, how many employers turn to the next CV at this point?

Anyway it looks like I am going to be finding out. My experience as a contractor so far is not encouraging.

My weekend jog through the park was particularly interesting this week. Not just because of the light sprinkling of snow, bright sun and freezing temperatures. I had to watch my footing every time I heard myself interrupt Geoff or forget someone’s name. Yes, I was on my own. And no, nothing wrong with my head. (nothing serious, anyway). I was listening to the latest agile toolkit podcast where Bob Payne interviews Geoff and me.

In a previous post I was rather critical of Bob’s interviewing technique, and perhaps this is justified. He is a really genuinely friendly guy though, who is warm and enthusiastic towards people and that does make up for a lot. In the interview he did make some random joke about Thoughtworks that I still don’t get, but on the whole I think we got on ok.

In the first part of the interview we talk alot about how TextTest grew up in an environment of long running batch processes, and a bit about the crew planning system that Geoff wrote it to deal with. I hope listeners don’t decide this is boring and switch of at this point, because it does do more than just that. I talk a bit about what we did with TextTest on ‘Programming with the stars’ and then we discussed what else it is good for (legacy code, and even greenfield TDD development).

I did try to think through beforehand all the things I was going to say, but intevitably I left out a couple of important points. Neither of us mentioned that TextTest is written in python but can test any language (so long as it can produce plain text log output). I didn’t make it clear that I don’t work for Jeppesen, rather my new employer IBS JavaSolutions kindly paid my conference ticket. I said that ‘I’ got the highest marks in the stars competition instead of ‘we’ (forgive me Michael and Geoff! We did it together, I know)

Overall I think the podcast is worth listening to though. I hope it will encourage some people to try out texttest, and write automated tests for some code that they thought was untestable.