Category: Jiri

Preparing to return to work

It has been a long break for me, and I have mixed feelings about what awaits me on my return to work. Most of the other staff also took the week off between Christmas and New Year (though Jiri did not). I am slightly embarrassed to admit that I always feel that I should invite Jiri round for Christmas lunch and never do. He is probably perfectly happy on his own.

There is the standard stuff that always appears when you have had a break. The stack of problems that people discover because they’re not really working but are exploring the software to have something to do. The new features that Gavin has invented while going on a long walk after an all-night party. The new contacts that David has made while playing golf on Boxing Day, and their suggestions for what is needed to penetrate new markets. The stale issues that people couldn’t deal with just before Christmas so they put on the pile to be dealt with after Christmas when they would feel more inspired and less jaded.

All the tinsel that draped the stairs and monitors has been put away. Jiri is very happy because he managed to get an enormous amount done while the office was empty. The cleaners haven’t been in over the new year so his desk is festooned with crumbs and empty packets of Czech festive items. Jack isn’t back yet – he’s gone ski-ing with his girlfriend. Mr Grumpy is in, and he is delighted to be back at work. For someone who complains so much, he seems to enjoy life far more than most of the people I know.

I promised that I would provide a systems analysis of the company and I am just considering how to do it. Like most small companies, it consists of a series of departments, each run by a manager. Departments contain some specialised staff and some people who have ended up there and learnt on the job. In a good company, the departments will be work-shaped. That is, a department has a function to perform and its staff and systems enable it to carry out the function within the department. That’s easy if it’s a closed function, but speaking from experience, every function will require (at the very least) information from the rest of the company.

For example, marketing has a big marketing push to carry out in the new year – get customers before the end of the tax year in April, when they’re likely to have some extra budget to spend. Marketing need to know all the stuff about customers patterns of purchase (which is their own skill) and they need to feed that back into the company. They also need to know what the company is producing that they can sell in the new year. How do they do that? Do they get the over-optimistic views of GandD, or do they get the more realistic views of Ian? Do they have to come and chase and check whether what they have been told is true, or will the right information be passed on at the regular meetings? Have they got the experience to discount GandD’s over-optimism, and if so, how do they know which bits to discount? This is not something that can be codified, because the (say) 30% of stuff to discount will change each time? This is skill, but to be able to learn the skill, you have to know what goes in and what goes out. You have to know at what point the product starts to stabilise and you have real information to deal with. And from that, you have to find out what customers want and feed that back into development.

So marketing has several roles:
1. To sell stuff to customers (this is how it’s seen within the company, anyway)
2. To understand what the company produces and when it will be ready
2. To understand what customers need and when they buy it (that’s their own skill that enables them to do their job)
3. To tell the company what customers need and when they buy it
4. To create a trustworthy competent public image for the company

Now Jeanette is fabulous at selling. She’s pretty good at knowing what the company produces and how much of GandD to ignore. And when to ask them what is actually happening. And when to tell them stuff is a waste of time. But I’m not sure how much all of her knowledge about customers – why they buy, and even more importantly, why they don’t buy, filters back into the company. Should it? Can Jeanette’s sense of what people want be as important as what David picks up on the golf course?

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.