Liz Keogh's blog

Reading Andy’s post on mixed feelings for Firefox, and continuing my attempt to loosen Micro$oft’s hold on me…

I’m leaving one bank because its internet banking doesn’t support Firefox. Their response to my request for Firefox support was “use IE6″. This, to me, is typical of their attitude to customer support.

Smile, on the other hand, have a site which I have run without trouble under Firefox. Not only is their interface great (if you like pink) but their customer service rocks too. So I will be sticking with them, and plugging them to all my Firefox-loving friends (and anyone who reads this).

Andy – can your client afford to lose my custom? Or 2% of the market? Or 5%? At what point does Firefox support become good business sense?

Why not encourage people to use Firefox, and steal everyone else’s customers as they slowly migrate to your way of thinking?

This weekend, I installed Ubuntu on my home PC.

It’s a bit buggy, but I have high hopes for it. Mostly it’s buggy because I don’t know what I’m doing, but I’m encouraged by the amount of help appearing online.

I think the best thing about it is that it’s designed for Linux newbies, so looking up “Ubuntu help mount windows FAT32 partitions” retrieves posts which doesn’t assume that you know where the fstab file is located, or what “uid=1000″ means. You also don’t get forumn posts saying, “Uninstall Windows…”; it’s pretty much assumed that you’re on the right path just by having a version of Linux installed. I’ve got a lot further with it than I did with RedHat, and I’m finding out all kinds of fun geeky stuff as I progress.

That having been said, my dreams of a Windows-free PC are a long way away. So many of my toys aren’t compatible with the Linux programs available – my iPod, my Palm PDA with DocsToGo, my Lego Mindstorms, my Scanner, my bluetooth dongle… the list goes on. And yet, the penguin has just sucked in another victim. Eventually, companies like Apple, Palm and DataViz will have to throw a bone to the Linux users… won’t they?

I’m writing a series of fantasy novels.

At the beginning of October, I finally reached the chapter halfway through the second book which I’d been looking forward to writing for a long while. I sat on the train, pen poised above the PDA, waiting for the words to come. They trickled in, slowly, but no matter what I wrote it felt dry, stilted and uncomfortable. The meeting between two of the main characters was intentionally awkward, but so, unfortunately, was the dialogue, the thought-stream and the flow of action throughout.

Finally, on Tuesday evening, I started rewriting the chapter from the point of view of another character, hidden and uninvolved in the conversation. Suddenly everything came clear. Six pages in two days is something of a record for me. Six pages in three months is not so good.

It struck me, thinking about it this morning, that efficient programming is all about reducing the gaps between those flashes of inspiration when code flows naturally, makes sense, feels clean and maintainable and not awkward to manage. Ward Cunningham said “our product is understanding” (a quote mailed to me by a colleague from this video). It takes one person a while to come to an understanding. It takes two people working alone the same length of time; neither of them can write anything until this happens. Put two people together, and understanding is reached much more quickly. Yes, both of them could take their understanding away and do some typing, but really, it’s much more efficient to just get the typing done and move on to the next inspiration gap together.

Like fiction, you can write code over and over again, but you’ll end up throwing 90% of it away if doesn’t actually do what it was meant to. If you find your code is stilted and awkward, the best thing to do is to look at it from a different point of view and try again. Ideally, get someone else to give you that point of view. Best of all, grab someone to pair with.

Unfortunately this doesn’t work with fiction, where you as the author are trying to give understanding of your story to others, who have none. Fortunately I have a number of characters on whom I can call for inspiration. So, if you occasionally see me sitting in a dark corner mumbling to myself, you now know why. I am my own pair.

An Executor is someone who deals with people’s lives after they’re dead.
An Executioner is someone who renders people dead.

Strangely, they both execute. What a pity this code doesn’t.

Last night I went to the XtC, where I met a bunch of very interesting people and discussed best coding practices and haiku.

We decided that while it would be lovely to see comments in haiku-esque form throughout code, to break up the flow of all those strange lines more than anything, it would eventually become distracting and annoying. It got me to thinking, though, about the nature of haiku and the purpose of comments. These thoughts were mostly spurred by Nat’s article on comments yesterday.

Most people make the mistake of defining haiku as “a poem with five syllables in the first line, seven in the second and five in the third”. The syllables are only really relevant if you’re writing in Japanese. It’s much more important when writing haiku that it should capture a moment in time, giving some unique insight into an everyday event. Normally haikus contain a “kigo”, or seasonal word, to indicate what time of year it is.

Another rule which I’ve heard is that the first line of a haiku should be immediate, something related to the writer. The second should be something more abstract, placing the poem in context. The third should deliver the surprising insight or twist. It struck me that this would in fact be a very good way to flavour three-part comments. The first part should be immediate and tell you why the code section is the way it is. The second should relate the code section to the rest of the system. The third part should deliver an insight which cannot be seen simply by looking at the method signature.

This means that the comment below (from my “Hellbound” variant of Tetris):

public void AbstractShape implements Shape {

    ...

    /**
     * Uses the rotated positions of the shape to determine how it responds
     * to movement.
     *
     * @param movement one of LEFT, RIGHT, DOWN, ROTATE_RIGHT or
     * ROTATE_LEFT. Do not pass the DROP event to this method - break
     * it into separate DOWN events until blocked instead
     *
     * @return true if the shape moves successfully, false if the detritus*
     * or the edges of the board block a move
     */
    public boolean move(String movement) {
        ...
    }

    protected abstract Point[] getRotatedPositions(int newQuarterTurns);
}

*the pile of dead shapes at the bottom of the board

is a haiku-esque comment, whereas this one:

public void AbstractShape implements Shape {

    ...

    /**
     * Moves this shape.
     * @param movement the movement which this shape should attempt
     * @return true if successful, false otherwise
     */
    public boolean move(String movement) {
        ...
    }
}

although shorter, is not.

The first comment tells me things that I didn’t know and ensures that any shapes I code which override this method adhere to a specified contract. It also tells users of the method what they can and can’t do with it (the can’t is more important, as it won’t be covered by tests). It tells me why the method behaves the way it does. It doesn’t tell me what the method does, as that’s covered by the method name and additionally by the tests.

The second comment doesn’t tell me anything which I didn’t know already.

It’s a terrible idea to include extra syllables in a haiku just so that it matches up to some preconceived notion of what a haiku should be. It’s also a terrible idea to include comments just because some strange style checker / team leader insists that you have to have them. A haiku should deliver a surprising insight in as short a space as possible. A comment should do the same. (Thanks, Nat!)

So. Time to go through the bits of code which I wrote before my recent enlightenment, and ensure that the comments are either beautiful or absent. I may need to do something similar with my poetry collection.

Finally, I will be joining the likes of Martin Fowler et al as a paid, published writer. Two of my poems have been selected for Star*Line, the Science Fiction Poetry Association magazine, and will hopefully be appearing in print later this year.

Admittedly, given the current USD exchange rate, my earnings won’t even cover the cost of a pint in my local – but it still means a lot to me!

I’ve started going through my Hellbound project and replacing some of the mocks I’ve been using in JBehave with real code.

This means, of course, that the functional tests which relied on the mocks for verification don’t do anything any more. In fact, the only way to test that Hellbound is working is by looking at the front-end.

I guess this is why packages like JFCUnit and Abbot were developed; to allow testers to get hold of the application guis and automate the tests. The only way to test a client-side application is by looking at the gui (or by checking output files, I guess). But by and large if the screen looks right, and the users can’t tell the difference between a back end made up of persistence layers and databases and J2EE technology, and a bunch of monkeys running round with bananas into which the data has been carefully etched, then it doesn’t really matter what the back-end is.

Hellbound is a game, so the users are happy if the game lets them play it. The system I’m actually being paid to produce is a retail till application, so the users are happy if they can sell things, and people are happy if they can buy things.

So really, the only way to test if your system works is if people are happy.

There are other ways to make people happy. I’m convinced that the secret of happiness, particularly in the kind of culture which permits retail till applications, is to look at what you’ve got and not at what everyone else has; to stop being jealous of success and wealth and start appreciating your own. So all I really need to do is convince the whole of western civilisation that there’s a better way, then it won’t really matter if my code works or not.

I have a sneaking suspicion that it might be easier to learn to write functional tests properly.

My current pair Dan and I got into a discussion about blame cultures. He told me about a meeting he was once in, in which the boss said, “We don’t want to start a blame culture.”

“Yes,” said another employee, “but it’s better than having a Teflon culture.” Dan told me that he’d worked in one place where a few employees had managed to mess things up, resulting in the project’s failure and the whole company going down the pan.

I reckon this is because some of them still had a bit of a blame culture, or at least a blame culture mentality. Blame cultures stop people communicating to one another. They stop people wanting to be involved, make people hold onto knowledge instead of sharing it (since being the only person with important knowledge prevents you from being fired) and cause people to avow responsibility for anything. The few people who do want to get involved and take responsibility invariably end up with all the blame and none of the appreciation. It’s happened to me.

“So what’s the alternative,” Dan mused, “when a few people can’t be bothered, or make mistakes? Where does the buck stop? How do you ask them, ‘Why haven’t you done this yet? Why’s this not working?’”

“You don’t,” I said. “You ask them, ‘Can I help you with that?’ It’s your project; it’s your responsibility too.”

“But how do you know when people need help?” Dan asked.

I shrugged. “Dunno. Everyone on this project just assumed I could use the help when I started. As a result, I’m not afraid to ask for help when I need it.”

So I’m learning things, and getting better, and I’m not afraid to start seemingly impossible tasks because I know that someone round here will help me and share their knowledge. Maybe there are people on projects who simply aren’t as good as others. A blame culture won’t help with that. People who aren’t good at their job are sometimes very good at hiding it.

I believe that sharing responsibility and communication is the best way to make good use of everyone, and find out how good people really are. It’s not an invasion of your privacy. Don’t think about it as “If you’ve done nothing wrong you’ve got nothing to hide*“. Think about it as “Everyone has something they can teach you – and you, too, have something you can teach.” Have courage. Be motivated. Take responsibility, and let other people see you enjoying it. Let people know that they can come to you for help without fear of blame. The worst thing that can happen is that you may find yourself in need of a new job. If it comes to that, you probably deserve one**. I did.

* The ID card scheme is, IMHO, another kind of blame culture.

**See also the White Book, Extreme Programming Explained, and my favouorite book so far, Extreme Programming Applied, which say much the same thing.

When I started here, I was secretly concerned. How could I ever hope to match my new colleagues’ motivation, let alone their technical skill? How could I find the time to mess with projects outside of work, and the passion to care about a job, as they did, beyond the 9 to 6 daily grind? I’ve always been enthusiastic and optimistic, but mostly that was just to keep me afloat in a sea of morose office robots. Even the best of the companies I’ve worked with in the past have had their share.

A month later, I’m a very different developer to the one I used to be; a neurotic bundle of wishes staring in futile desperation at my screen, smile fixed rigid in hope of some joy. Here are the important things I’ve learnt over the last month which may help those of you still stuck to survive the robot sea.

• Blame cultures are quagmires, trapping everything that comes into them and drowning even the best of developers. If there’s one thing that I could convince every company in the world to get rid of, this would be it.
• It’s worth keeping motivation and enthusiasm up, even on the darkest of projects. It keeps that all-important “passion for technology” alive, and gives you hope for the future. Without it, you become a morose office robot. With it, you can infect other people. This in retrospect, as motivation is no longer a problem.
• It’s worth asking about things you don’t understand. Your company hired you for a reason; they don’t necessarily expect you to be an expert on day one. Pretending you’re an expert and floundering through stuff isn’t as much fun as persuading people to teach you New Things. If you’re lucky enough to be an expert, please – teach the rest of us New Things.
• There’s more than one Right Way. Well, maybe that’s not true, but since even the experts debate over which is the Right Way, it’s worth getting to know a few of them. Be open to new ideas.
• Given fertile ground and some seeds on the wind, things will grow. Similarly, given the right environment, passion for work just happens. You don’t need to find time. Let it find you.
• Having said that… substituting coffee and sugar for sleep may be amusing in the short-term, but eventually you need to step away from the screen.

Oh, Lotus Notes.
I was rude to you
In December.

You ate my email.
Isn’t that revenge enough
For those words?

Don’t hang like that.
Don’t leave me with no choice but
To kill you.

I pity you.
You’ve never known what it is
To be loved.