Herding cats

I love software. And even more than software I love code. I wish I was a better coder. I am what you would call a habitual cowboy. I crank out vast amounts of code in very little time and rely on the dark arts of refactoring to actually clean up after myself. Although I rarely do.  But this isn’t really about me. I don’t really do much hands-on work these days. Well a little, but since I know my faults I try to keep myself in check doing test-driven development (and it usually works, believe it or not).  These days I generally work with developers in some form of a managerial capacity. Which means I tend to walk around, look over people’s shoulders, ask the annoying questions, check their time estimates and generally ask how everyone is doing and make sure that things are running smoothly. Which is a lot like herding cats.

 Since I like talking about myself I’d like to tell you a little thing about me. A couple of years ago I was interviewed and got a question which went something like this. “What is the biggest secret in your profession”. To which I answered “Your developers are lying. And if they aren’t lying they’re wrong.” I got a substantial amount of grief for that comment but since then I have worked with a couple hundred more software developers, systems architects and technical support engineers and what has struck me is that it’s still true. People answer questions without thinking them through. They do time estimates that are wildly off, either being so hysterically optimistic that it’s laughable or so pessimistic that you are getting into geological time to build an application which a shaved monkey could write standing on his head while singing “I’m a yankee doddle dandy”. If you could find that monkey, please let me know. I might have a job for him. Now, everyone tells me that it’s the project managers who are supposed to handle this. The only problem is that they don’t, if you look at the statistics the fact of the matter is that a large percentage of projects either fail, completely tear their budget to shreads or underdelivers on quality, functionality or in most cases both. Yay and way to go to all of you project managers out there. Two years ago I saw a project that went from 13 000 man hours to 26 400 man hours. Why? Nobody knows. The question was put forward and first the answer was the usual. “Feature creep”. Well, there wasn’t any substantial feature creep. Then it was “lack of continuity”. Wow. Well, there wasn’t any real lack of continuity either. It just turns out that the project in question had misestimated it’s time by just a shade over 100 percent over the orginal estimates. Well done. Applause. I won’t even go into the fact that the product itself was of such a crappy quality that it cost the company in question quite a bit of money and a customer. Impressive indeed.

So what do you do? I think SCRUM offers some help actually. It won’t work for the huge projects without breaking them down into smaller sub-projects but seriously, you should do that anyway. In any case, the developers and systems people have to be involved, have to have a stake and they have to know that they are measured and appreciated for their work. And they have to have some sort of pride in what they do. See software development is kind of a crap thing to be doing. My grandfather, a big silent man who rarely spoke but often took me for walks around the countryside where he lived, used to point out things he had helped build. “We built that barn over there in 1933, after the old one burned to the ground”, he could say, pointing. There were houses, barns and above all hundreds of pieces of furniture that he had built and which will remain in use for potentially hundreds of years. Us software people aren’t that lucky. In fact, I used to work with a guy, a nice and friendly and comptent developer, who had never in his 10 year career ever been involved in a project that succeeded in shipping a final product. And even if we do they are ephemereal, they don’t last. I won’t be able to point to my grandchildren and say “Look, your grandfather helped build the voicemail system for that operator over there”. Everything will be gone. So pride has to come from something else, they have to know and understand the business impact of what they are doing or you will keep running into the same problems over and over again. Here’s a simple symptom that you can look for in your own organisation: do the developers constantly complain about the stupid requirements from the sales organisation and from customers? Bingo. You have a problem. There are ways to manage that and to resolve it and I’ll write something about that tomorrow. Or some other day.


About this entry