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.