Another moment of fury

Back at work. This time my fury was inspired by Jack. He has been occasionally closeted with GandD over the last couple of months, and today he was demonstrating his cool new stuff.

Cool it may have been, but only in the sense of an approaching iceberg. We (in theory) have until the end of January to finish and test the latest release. Three weeks, loads of time isn’t it? That could be my new nickname for Jack “Loadsatime”.

For reasons best known to himself and GandD, they didn’t want, well, anyone with experience of users, such as myself, training or support, to comment (or even know about) the new features until they were properly implemented. So this was the gleaming remove the drapery moment; cut the red ribbon and reveal the glorious finished product.

Except, is there a way of putting this tactfully? Except there is no point in asking for feedback on a finished product unless the only feedback you want is “Isn’t it mahvellous dahling”.

What is that there for? Oh, I thought it might be a good idea. Do users need it? I don’t know. Is that very important bit that users might actually want to use easy to find? Well, it’s obviously really easy, you just open this dialog and find that button and then set this option…. You can imagine the rest. And, given the fact that there is three weeks left, they aren’t going to change anything at this stage, are they?

Admittedly, he did have three cast-iron and valid excuses
1. Gavin wanted it like that
2. David wanted it like that
3. It would have taken months to implement in a sensible way.

Well, maybe excuse no. 3 isn’t that valid, because it hinges on that big elephant in the sitting room, well, not merely an elephant in the sitting-room, there’s a volcano in the bathtub, a hyena in the kitchen, and fourteen zombies locked into the attic bedroom.

And they’re all asking the big question?
How are priorities set?

Loadsatime Jack can’t set them, because he does what GandD ask him to do. They have a difficult call to make.

First, they have limited development resource.
Second, they need to use it in a way that brings in returns

Some things, such as re-writing the whole thing from scratch, just ain’t going to happen. Not unless we get a massive injection of cash from some venture capitalists. And GandD wouldn’t sell their company unless it was sinking.

How can I persuade them that a project that is easier to use may be more worth having than one with more features?
How can I demand that a lot of that limited development resource is spent on making existing stuff better, rather than adding new stuff. At the moment I can’t think.
But perhaps I could persuade them that involving the idea of the user earlier in the process would be a good plan. Before they decide which features go in, even. At the moment though, I think I’ll just go out for a long walk and avoid the undead for tonight.

Why do I think it happens like that?

When you’re creating a new product, it’s like the band’s first album, or a first novel. You can put all your best work into it. All those hours of sitting in a back room, thinking of how it should work while you’re supposed to be doing something else. All those evening hanging out with your mates and discussing it (for a band) or those rich ideas that have bubbled up for years (for a novel).

Then comes the new release. It’s the follow-up; the second album that flops or the second novel that arrives with hype and leaves with its tail between its legs and an apologetic wet spot on the floor.
(Of course some of it is straightforward regression to the mean: great one time means more likely to be not so great the next.)

In both cases, you normally have a clue what it’s like when you make it, but it’s only when it’s bought that you really understand. People react to what you’ve done. And software is interesting, because it’s a tool. Users use it. They don’t just listen to it or read it. They want to make stuff happen with it. And what they want to do may or may not be what you think they want to do: or even what they think they want to do.

They find bugs. They find things that they want to do and can’t. And if you’re lucky they phone up the support desk or email in or write on forums so you can find out what their problems are.

So, in your second release you fix the bugs (obviously) and you add some of the features that youwanted to put in the first release but couldn’t, and you put in some of the features that you discover that users really want that you never thought about. And that is where it all starts to go horribly, horribly wrong.

Let us imagine our basic Dalek with exterminate facility. You have choices when working on the upgrade design:
a. add levitation to deal with the “cannot conquer a world containing steps” problem
b. assume that wheelchair access will become normal so that Daleks will learn how to campaign for it c. point out that Daleks were never designed to conquer the world, they were designed to be defeated, so use them in the way they were intended
d. redesign the sink plunger
e. offer people a re-badged helicopter that can carry Daleks

Gavin, obviously, wants to add levitation, because that is the correct solution and it has interesting coding challenges. David wants all the other things because they are fast and cheap and there is a massive mark-up on the helicopter. Nick would like to work on levitation because that is an interesting problem, but he designed the first sink plunger so he knows that he will be the sink plunger re-designer. Mr Grumpy and Jack are supposed to be fixing bugs. Both of them have a talent for introducing new bugs. This is because they don’t realise the side-effects of their fixes. Mr. Grumpy doesn’t always bother to find out how the code he is debugging is supposed to work, so he breaks other bits while getting the first bit to run smoothly. In Jack’s case it’s just because he writes it badly. Jiri has already started researching levitation techniques and has found an interesting paper that implies it can be done very efficiently if you can redesign the Dalek so it doesn’t require a sink plunger.

Ian tries to find out whether there is going to be levitation or not. He knows that Gavin and David are arguing about this and whichever one he meets in the corridor will tell him something different. He sits down and writes the spec as he understands it, so at least there is something for all the developers to do until the decision is made.

And I try and find out if users actually want levitation, or whether they really want to use the Daleks as pest controllers and would like a fumigation option.