Liz Keogh's blog

Last night Dan and I presented JBehave 1.0.1 to the assembled masses of Thoughtworks UK.

“Seriously though,” one spectator commented, “no one really does any of this AgileDocs stuff. Who actually reads the names of tests to find out what the code ought to do?”

On a project in which the tests consistently describe the behaviour of the code, the answer is: everybody.

“Okay. But why is it always so hard to write good tests?”

1. Your tests are not actually describing the behaviour of your code

I frequently see tests which describe the behaviour of a dependency too. A dependency is anything which is used by the thing whose behaviour you’re trying to describe. eg:

The driver should stop at the zebra crossing.

vs

The driver should press the brake pedal at the zebra crossing.

The car should stop when the brake pedal is pressed.

2. Your code is wrong.

This happens a lot to me if I’m pinning down legacy code, and I’ve assumed that the method called getTheOneRing() does actually do what it says it does. If I find I’m getting a copy back instead, there’s really no point checking that it’ll melt in the fires of Mount Doom.

3. Your code has too many responsibilities.

It’s probably doing something better done in another class; think about introducing another dependency (like a Car).

4. You’re trying to mock too many classes.

See 2 and 3.

Don’t mock domain objects. Your code should interact gracefully with them, and be able to rely on their behaviour. Mocking domain objects leads to fifteen expectations per test, and gives you no better certainty that your code is behaving itself.

Don’t mock data structures (which are frequently domain objects anyway).

Split dependency classes which consist of mixed data structures and methods to manipulate the data. That way you only need to mock the manipulations. (As an example, consider the separation of Pattern Matching and Strings). Or, even better…

Use role-based interfaces to limit the scope of dependencies. Your code should perform according to its responsibilities; it should depend on roles which help it to perform those responsibilities. If a driver’s only responsibility were to pressTheBrakePedal(), then a driver would only need a Pedal, not a whole Car or even a Hydraulic Braking System.

A pattern I use sometimes

If I have a Driver that needs a Pedal, I might define it as a public inner interface of the Driver.

Adapting from a Car.Brake to a Driver.Pedal turns out to be easy, for most instances of Cars, Drivers, Brakes and Pedals – and if, later, you want to put in that super duper new parachute breaking system for jet-powered vehicles, you can do so and adapt to the Driver’s pedal requirements without changing the behaviour of the Driver.

I don’t know.

Seriously, I don’t. I’ve never encountered any big barriers which have stopped me wanting to be in IT, nor have I met with any problems being involved with JBehave. I hear rumours that the Open Source world is full of misogyny, but I’ve been fortunate to encounter only brilliant people who I respect greatly, and who respect my skills, however limited they might be, in return.

I see the occasional XYZ is for girls post, and some people are surprised that I’m capable of creating more than “Hello World”, but by and large such thoughtlessness is gentle, and often done in humour, intended to be funny rather than unkind (and I’d rather we laughed than tiptoed around blatant stereotypes).

I guess not everyone is that fortunate. Kathy Sierra recently received violent, sexual death threats, and is no longer attending the conference at which she was due to speak.

I’m genuinely shocked, and I feel incredibly naive and grateful at the same time. This is so far from my world.

Good luck, Kathy. Hope they catch them.

• Because our customer doesn’t know what he wants, he finds out from the people that want the system. He sometimes gets this wrong.
• Because I don’t know what to code, I find out from our customer. I sometimes get this wrong.
• Because I make mistakes while coding, I work with an IDE. My IDE corrects me when I’m wrong.
• Because I make mistakes while thinking, I work with a pair. My pair corrects me when I’m wrong.
• Because my pair is human and also makes mistakes, we write unit tests. Our unit tests correct us when we’re wrong.
• Because we have a team who are also coding, we integrate with their code. Our code won’t compile if we’re wrong.
• Because our team makes mistakes, we write acceptance tests that exercise the whole system. Our acceptance tests will fail if we’re wrong.
• Because we make mistakes writing acceptance tests, we get QA to help us. QA will tell us if we’re wrong.
• Because we forget to run the acceptance tests, we get Cruise Control to run them for us. Cruise Control will tell us if we’re wrong.
• Because we forget to maintain the acceptance tests, we get QA to check that the system still works. QA will tell us if it’s wrong.
• Because we only made it work on Henry’s laptop, we deploy the system to a realistic environment. It won’t work if the deployment is wrong.
• Because we sometimes misunderstand our customer, we showcase the system. Our customer will tell us if we’re wrong.
• Because our customer sometimes misunderstands the people that want the system, we put the system in production. The people who want it tell us if we’re wrong.
• Because it costs money to get it wrong, we do all these things as often as we can. That way we are only ever a little bit wrong.

Do you find that your pair prefers to drive, even though he’s happy to navigate with others?
Do you wish that you could concentrate on the words on the screen, instead of the disjointed letters under your hands?
Do your fingers fly over the keys, or do you stumble, two-fingered, in a desperate attempt to put your thoughts down before you lose them?

I find it hard to think of anything which has increased my productivity more than the ability to type quickly and with a reasonable accuracy. I’m lucky; my dad bought me a typing tutor as a child, and the many years spent chatting over IM or on MUDS honed it to a top recorded speed of 78 wpm. That’s faster than I can actually assemble a lucid sentence!

Most secretaries need to type at about 50 wpm. I think a coder, whose typing is less about words than combinations of odd symbols and the occasional keyboard shortcut, should be able to manage at least 40wpm. If you can’t, please – for the sanity of your pair – think about learning. There are a number of things that you can do which should help.

• Get a cheap keyboard, and put stickers or tippex over the keys. Start with the home keys – they’re the ones on which your fingers rest when you’re not typing: ‘asdf’ and ‘jkl;’ on a qwerty keyboard – then expand up, down and out till you know all the keys by heart.
• Be brave! Be strong! Get a Das Keyboard, which comes boxed ready-tippexed (well, they don’t bother putting the symbols on in the first place).
• Google “typing tutor”. You want to find one which concentrates on the home keys first, as this will help prevent you from getting into bad habits. Don’t be put off by having to type fff jjj ffjj jjff fjf jfj for the first five minutes. It really is important to get the home keys in place.
• Practice! Talk on IM; play MMORPGs and find a bunch of friends to chat to; write letters home; copy out your favourite stories or poems.
• Write code for fun! and use the command line whenever possible.
• Your mouse is a tool too. Minesweeper is really good for developing mouse coordination.
• Don’t let your pair talk you out of driving. Tell them that you’re learning, and ask them to have patience. It may take longer to start with to find the keys by touch, but you should start seeing your speed increase within a week or two.
• Don’t look down!

http://blog.versionone.net/blog/2007/03/a_few_good_mana.html

Once in a blue moon comes a piece of writing so funny that we stick it on our fridge.

Customers: do you wish you had a better idea of what your expensive app was doing?
BAs: do you wish the Devs spoke your language?
QAs: do you want to write executable acceptance tests in English? Would you like to know what the Devs are really running?
Devs: do you want to cross that communication bridge?

If you’re one of these people, or just curious, pop over to the JBehave Story Framework or check out the examples in the source!

The JBehave team is delighted to announce the release of JBehave 1.0!

Please try it out and send us feedback.

Features include:

• Behaviour runner – equivalent to JUnit 3.x
• Story runner – runs executable scenarios / acceptance criteria
• Story printer – outputs stories and scenarios in human-readable form
• Minimock framework – a lightweight mocking framework based on JMock 1.x
• Classmock framework – allows minimock to mock concrete classes
• A Swing harness – minimal and fast
• Eclipse plugin – runs behaviours in Eclipse
• Ant tasks – run behaviours, run stories and print stories using filesets
• Maven integration – apparently!

Documentation will follow soon (days, not months); in the meantime we suggest that you use the Hellbound examples in the source to guide you.

Many thanks to the team and contributors for all their work.

Marc challenged us today:

Oh, and does anyone have a succinct definition of the difference between lean and agile?

I’ve been thinking about this too, and had an epiphany.

Agile focuses on early delivery; it handles changing values.
Lean focuses on cheap delivery; it minimises waste.

Since unsuccessful delivery would be waste, Lean happens to focus on successful delivery; and since delivery of poor value requirements would be waste, Agile has some focus on cheap delivery. But Lean’s focus is all about trimming the fat everywhere, whatever other practices and processes may be used, and I think it therefore represents better value-for-money.

I accept that Agile has taken some practices from Lean, and that its focus may have shifted somewhat, but I’m pressed to think of a practice that Lean’s taken from Agile. I also accept that I’m biased towards the meaning of the names of each of the different practices, and the focus which those names have impressed upon me. Since names suggest behaviour (consider horses called Thunder and Buttercup), I expect that others might be similarly biased, whether they know it or not.

Forty people in a meeting? Are you mad?

No. At least, not in a relevant sense.

But it’ll take half an hour!

There are some tricks that you can use to keep the stand-up short.

• Rule 1: Only say things which the whole team needs to hear.
• Rule 2: Do not get into discussions about these things.
• Rule 3: Each participant has the right, but not the obligation, to speak.
• Rule 4: Split into, say, 3 smaller teams, or streams, for more focused standups. These can (should?) be held immediately after the big stand-up.

Why not just get the leaders of the teams together, like a Scrum-of-scrums?

• It makes the team feel like a team, rather than 3 sets of people who don’t know each other.
• It gives even the least important devs a chance to speak
• and to realise that the input of even the least important dev may be crucial to project delivery.
• It’s possible to get feedback about the feelings of people for the project from the number of smiley, fidgety, awake, bored, dejected or exhausted-looking people in the room.
• It makes everyone turn up at the same time, which – if the standup takes less than 2 minutes, as it should – means they’re on time for the team standups too.
• People who get a chance to make eye-contact with people who are not on their stream are more likely to communicate with those people. That helps prevent the people who might otherwise attend a scrum of scrums from becoming communication bottlenecks.

You can always have a scrum-of-scrums as well.

How can I keep my 40-person stand-up short?

• Pass a token (we use a beanie-baby zebra) around the ring of people. Anyone can raise their hand to ask for the token, if they have forgotten to say something or have a response.
  • People don’t stand around wondering if it’s their turn to speak.
  • When the token has gone around the ring once, unless anyone asks for it back, the stand-up is over.
  • It feels uncomfortable to throw the token back and forth between two people, so anything other than a quick “I’d like to talk about that later” is thus discouraged.
  • People smile as they watch the comical stuffed toy being thrown around between otherwise mostly sensible adults. Smiling is good for you.
  • The weight of responsibility in holding the toy is felt more keenly than any effect of gravity on its mass. This encourages participants to keep it short.
• Remind participants of the rules if it seems as if they’ve forgotten.
• Don’t wait for people to turn up! If you’ve said you’re running it at 3pm, run it at 3pm. The slackers will get the drift.

How do you find 40 people willing to participate in such a fiendish scheme?

1. Chocolate
2. Coffee.

is at virtualnames.co.uk.

I mention this because they have consistently responded to my support requests within 4 hours, sometimes going beyond the scope of my contract to allow me to do cool stuff.

Good service rocks.