Liz Keogh's blog

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.