Managing managers follow-up

I just wanted to point people to Joel's Evidence Based Scheduling. A lot of people often misinterpret my rant about estimates being an impossible dark art as going against tracking like the one developed by FogCreek (damn I wish I was attending their talk in London). The reality is that what I'm saying is reflected in the model:

The mythical perfect estimator, who exists only in your imagination, always gets every estimate exactly right.

Most estimators get the scale wrong but the relative estimates right.

And the one I'm the most in tune with.

When the project begins, the technical managers go off, meet with the business people, and come up with a list of features they think would take about three months, but which would really take twelve. When you think of writing code without thinking about all the steps you have to take, it always seems like it will take n time, when in reality it will probably take more like 4n time. When you do a real schedule, you add up all the tasks and realize that the project is going to take much longer than originally thought. The business people are unhappy.

Inept managers try to address this by figuring out how to get people to work faster. This is not very realistic. You might be able to hire more people, but they need to get up to speed and will probably be working at 50% efficiency for several months (and dragging down the efficiency of the people who have to mentor them).

You might be able to get 10% more raw code out of people temporarily at the cost of having them burn out 100% in a year. Not a big gain, and it’s a bit like eating your seed corn. Of course, when you overwork people, debugging time doubles and a late project becomes later. Splendid karma.

This all comes down to estimating a release date, certainly not thinking that your original estimate will be any accurate, because it won't. What do you end up doing?

If you do make a schedule, even before you start working, you’ll realize that you have to cut something, so you’ll cut the easy/fun feature and just do the useful/important feature. By forcing yourself to chose some features to cut, you wind up making a more powerful, better product with a better mix of good features that ships sooner.

I'm feeling happier today. Now go and read Joel, I don't agree with his prose all the time but his articles are deep and show a level of understanding of the writing software process that never ceases to amaze me.