Liz Keogh, lunivore

Lots of better people than I have written excellent posts about how, in any system, people will play it to get the best reward. It’s not just software:

• If a teacher is rewarded according to the success rate of his classes, he has less reason to encourage less able students to stay.
• If a council is threatened with a budget reduction if they don’t spend it all, they will find ways to spend (waste) it.
• If a civil servant is paid according to the number of people who work for him, he has no reason to encourage efficiency amongst his staff.
• If the money a criminal can stash away is more than he could earn in his time spent in jail, then crime pays.

And we wonder why the UK is going downhill.

These are the things which prompted me to write this, which are software-related:

• If a customer creates separate budgets for ‘bugs’ and ‘enhancements’, the owner of the enhancements budget has no impetus to keep the bug count low.
• If a customer writes a full specification for a story, the dev team have no reason to hold a conversation with the customer (story cards are placeholders for a conversation, not replacements for it).
• If a bug doesn’t affect a user’s paycheck, working hours or sanity, the user has no encouragement to report it (regardless of how it might affect users in other departments).

Games are fun. I’ll try to think of some more positive examples (or steal them from comments if you’re kind enough to let me.)

Today, we had a lunchtime meeting about our ever-contentious functional test suite.

Who cares about the functional test suite?

• The customers really care about our functional test suite. I know, because when I was on the dev team I had pretty senior people coming up and asking me what coverage we had, and how certain I was about the system working.
• The analysts really care about our functional test suite. Most of our tests check that the stories they’ve written have actually been implemented correctly. When we show an analyst an Abbot test running through the gui, they get to see whether the way we’ve interpreted their story is actually the way they meant it to work.
• The devs, who are nominally responsible for the functional test suite, really care about it. With it in place, they can tell that their fixes aren’t causing bugs in other parts of the system.
• The support staff really care about the functional test suite. With it, we can check that bugs in one version of a system won’t be there in the next one. We can provide interim workarounds with the knowledge that they really will be a temporary measure, just until the next version comes in, and we have more confidence that there won’t be any new bugs introduced.
• The end users, whether they know it or not, really care about the functional test suite. If the functional tests are working, then the application is more likely to work correctly and their lives will be easier.

And the only reason the functional tests aren’t running, and haven’t been for a month or so, is because big companies being the way they are, the desire to get a new machine for the new code branch got lost in the pipeline. A few devs thought the customers didn’t care. The other devs thought the rest of the team didn’t care. I (on support) thought the dev team didn’t care. The end-users almost certainly think that support staff don’t care. As soon as some of us got together to talk about who stopped caring, though – whose decision it was to forget about the tests – the answer was:

No one. See above.

And who wants the tests back?

Everyone!

We all really want the functional tests. And there’s got to be a spare machine around the office somewhere. Who cares enough to find one and set it up? We’re not short of volunteers. And suddenly, the ever-contentious functional tests are once again our much beloved functional tests which let us know that everything’s all right, unless there’s a little bit that needs to be fixed. (There might be a few big bits by now, but at least we’ll know, and we care enough to do it.)

So maybe, if it looks as though nobody cares, we should just talk to each other (there’s a surprise). Chances are that if it’s important, people care. Nobody ever actually stops caring, unless they get the idea that nobody else cares either – which is why it’s so important to go out there today, smile, and care about your job.

Reading about Neal Ford’s frustration when trying to explain Agile reminded me of this:

“The best way not to be unhappy is not to have a word for it.”
     Douglas Adams, The Hitchhiker’s Guide to the Galaxy

I guess if the only thing you’ve ever experienced is Waterfall, the illusion of control that it gives can be comforting. Agile practices don’t do much good for illusions. So if brutal honesty isn’t your thing, you’re probably better off with the old way. Maybe it’ll work, maybe it’ll fail – but at least you’ll have the comfort of never quite knowing why.

On Friday, I ran a workshop to teach some of my colleagues how to write haiku (a haijin is a haiku poet).

Many pleasant surprises: the number of people (I suspect they were press-ganged), the willingness of all participants to try, the way in which they critiqued their own poetry and sought feedback and suggestion, but most of all the fact that every single person added to the renga, a series in which each verse is inspired by the previous one, and everyone gets a turn – the ping-pong programming of poetry.

I did expect that everyone would end up producing something unique and beautiful, but it’s always nice to be proved right.

Fantastically, three of the participants said that they would indeed go away and practice reading and writing haiku in order to improve their vocabulary, fluency, non-procedural thinking, communication, concision, imagery… well, my conclusion for the session is that while there’s no single skill which the art of haiku can teach, there’s a wide range which can be improved. Everyone had fun. Most found it useful. I count that a success. Now I can relax again, until the next time.

If anyone out there feels like reading a little poetry today, I recommend TinyWords and the Scifaiku group at Yahoo.

Some time ago, someone – let’s call him George – changed all the tests I had written for a batch of Support classes which had been created as a “temporary measure” and had now become part of the system. The tests started failing, and several of them were no longer testing the things they had been.

I found out today. I’d spent ages working out what the various classes were doing. I’d spent ages pinning down the behaviour and decoupling everything, and writing tests for all the new functionality I was adding. He’d broken my code. I was very annoyed. My instinct was to chew him out; to scream in frustration, because he so obviously didn’t get it. And it was his responsibility – right?

I don’t like blame. It’s never useful. Instead, I went for a glass of water and calmed down. When I came back, I invited George to join me for a cup of tea on the comfy seats downstairs. We had a long conversation about the culture of non-communication in the team; the fact that there were so many new people joining, and that he, as the most experienced person there, had a great deal of knowledge and wisdom to pass on. George mentioned the regular meetings which had somehow slipped by the wayside, and I agreed that it was a good idea to resurrect them. I suggested that we should pair on the problems we were investigating and invited him to do so with the new guys whenever possible, and to put that culture back into place. Eventually I got round to explaining that the conversation had been prompted by the failing tests (and by my rather possessive reaction; another reason to pair). We had an equally constructive conversation about the importance of running tests, some steps which we’ll both need to take to make sure they stay running (since there’s no Cruise Control on our little Support team), and some things I can do to make them less brittle and easier to understand.

When I got back upstairs, I had a quick chat with The Boss, and told him I’d only postpone my roll-off date if he helped put those ideas into action. He agreed that it was about time something was done, and said he’d help me do it. Turns out that the guy who used to be the major proponent of communication – the meetings, the conversations, the pairing – has left. So now I’m taking his role, because at the end of the day, this is my project too; and if I have a problem with the way things are going, it’s my responsibility to change it.

So much better than stamping my feet. And saves on the cost of new shoes.

Us poor souls on your Support Staff are just another kind of end-user. Our Gui is made up of logs, reports and audits. We need love too! We need the same kind of attention to our needs as you give to your end-user.

So I have an idea.

Every time I’ve seen QA raise a bug with a dev team, the dev team has requested step-by-step instructions on how the bug can be replicated. This is true of every project I’ve seen where a separate QA team have been involved.

Stop it!

By all means, QA should record how they did it, but keep it secret. Get your other end-users in first. If Support can’t diagnose what QA did, they won’t be able to work out what your end-end-user did either. If Support need to ask QA how they did it, then there might be some information which needs logging – or maybe even auditing.

It really helps if QA consists of the most cunning, mean, dishonourable scoundrels available – or at least, good method actors who can think like them. If QA try to cause problems, to get hold of free money / goods / services / time off / promotion / someone else in trouble, it helps to differentiate the things which can be communicated, from the things which need to be logged, from the things which need to be audited. It’s not just because the end-users are also scoundrels. They might be the sweetest people in the world, but mistakes happen.

You can guarantee that in a big enough system, if someone can steal sheep without anyone noticing, the sheep will go missing without anyone noticing too. And it’s no good asking us why the software thinks there should be two more sheep in the field than there actually are if you don’t keep records, five sheep died, three were legally bought, one was stolen, there’s a six foot hole in your fence and you’ve let in the neighbour’s goat.

(My current client is pretty good at counting its metaphoric sheep. Goats next iteration.)

If you think you’re going to finish reading all those books you bought, you need more books.

As part of my preparation for a workshop I’m running next week, I’ve been studying the art and science of Mind Mapping, and the idea of Radiant Thinking which mind maps express.

I have to admit, scribbling with felt tip pens on big bits of paper taps straight into my inner child. I’ve been practicing mind mapping exercises, exploring concepts like “Why it would be fun to buy a Gnu” (the wildebeest, not the software), or “Why I should learn to drive”. I have the strongest feeling that at some point in the near future, my brain will go “Click! Ah! The non-linearity! The colours!” and never look back.

There are only a couple of problems, as far as I can see, with the use of mind mapping as the external form of radiant thinking:

1. it takes ages
2. you can’t do it on a bus.

I suspect the first of these things will be solved by practice, and a better appreciation for the benefits of having a finished map.

To solve the second problem, I have another mechanism for externalising the images in my head. It’s been practiced for centuries, and was invented by a bunch of guys whose language is mostly made up of pretty pictures anyway. Admittedly, it can only deal with very small subsets of a map at a time, but I particularly like it as it helps connect words – those things you use to explain your ideas to other people on a bus – to images – the things at the base of thoughts, whether concious or otherwise. In this context, images include all other captured sensory moments – smell, touch, sound, taste, awareness of the passing of time, etc. – in fact, all the things which the Buzans’ book encourages the reader to include in their Radiant Thinking representations. That this mechanism uses words instead of pictures directly is a necessary compromise, given time and speed bumps, but at least it cuts down the words to the smallest number that could possibly give expression to the thoughts.

Haiku. Pico mind maps for the busy commuter.

When code is refactored, the tests associated with it help you to be sure that you haven’t broken anything.

But code doesn’t test the tests! If you’ve ever renamed a test and accidentally typed tsetThat... at the beginning, you have already experienced this.

So, here’s what I do to make refactoring tests safer. First of all I work out what element of behaviour my test defines:

public void testThatWhenSaleIsMadeReceiptIsPrintedWithAppropriateAmount() {

    LoginScreen loginScreen = new LoginScreen();
    loginScreen.enterLogin("Liz");
    loginScreen.enterPassword("Pa55word");
    loginScreen.clickOk();
    SaleScreen saleScreen = new SaleScreen();
    ...
    assertEquals(10.00, receiptPrintOut.getPrice());

}

and I break that behaviour by changing the code, maybe by adding an exception:

public class Receipt {

    ...

    public void print() {
        ...
        /** @todo remove this exception */
        if (price == 10.00) { throw new Exception("Remove This"); }
       ...
    }

    ...

}

then I refactor the test against the red bar!

public void testThatWhenSaleIsMadeReceiptIsPrintedWithAppropriateAmount() {

    new LoginFixture().login();
    ReceiptPrintOut receiptPrintOut = new SaleFixture().buyItem(9123456);
    assertEquals(10.00, receiptPrintOut.getPrice());

}

As long as the test is failing because of my broken code (and not because of some null pointer which means that I’ve broken the test), it’s likely that it’s testing the right thing. When I remove the exception in the code, and see my test run green again, I have the same certainty that my test is still behaving itself as I do when I’m refactoring code. I can remove the exception at any time to check that my test still works.

For me, this technique has been particularly useful for those interminably long acceptance tests which have lots of duplicated functionality, or any complex change that my IDE couldn’t handle automatically. It’s also good for introducing mocks and stubs to tests; eg: introducing a stubbed data source instead of a real database, a custom output stream instead of a file, etc., as I know I won’t accidentally miss out the thing I was testing in the first place. I’ve also used it for refactoring an Ant build, to check that the patternset and classpaths I was using were still finding the tests.

It doesn’t always work, especially since acceptance tests frequently check more than one thing, but it helps.

So that was XP2005. What an amazing five days.

Thanks to everyone who ran tutorials and workshops, presented papers or took time out from the northern ale to chat to me in the bar, and everyone here who let me go. I learnt so much and had a lot of fun doing it.

Highlights for me included:

• Charlie Poole‘s UI Testing tutorial, in which we learnt the how, when and all-important why of UI testing (sometimes you don’t have to)
• The Coder’s Dojo, in which we worked on the Game Of Life rules, and how to discount Harry Potter books
• Sitting outside on the grass, struggling with an out-of-sync clapping rhythm in the Music of Agile Software Development
• Laurent and Manu’s writing workshop, the amazing freewriting exercise and the feedback from the other attendees
• Learning how to sell XP to customers, and sharing some of the stories of pain and triumph
• The exhausting but entertaining exercise in The Drawing Carousel, and finally finishing the picture of Jack running for the beanstalk with a hen beneath his arm (Hubert Baumeister took pictures)
• Kent Beck’s closing speech on moving XP up a notch
• Feedback from new friends on pretty much every concept in my head, their patience in listening to me during various question sessions and their encouragement of my search for knowledge and understanding of Agile and XP.

I hope to run an Agile Haijin workshop at TW soon, in which we write haiku, learn about Eastern vs. Western ways of thinking, investigate parallels between Agile practices and haiku and learn to do The Simplest Thing Possible. Should be fun.