Developers don’t like schedules. Sure, everybody agrees that they are a good thing, theoretically. There are loads of advice on how to do them. Still nobody likes making them, or using them. It seems that making schedules is like taking the rubbish out. Or worse.
One of the reasons is that a honest schedule can destroy your self-image.
Ask a programmer how long it will take to write a single class. Most likely, the answer is something like: “two hours”. It’s a lie.
Sure, it takes about two hours to write down the code. But writing a class also includes design, testing, documentation, communicating the requirements, and so on. Writing the class doesn’t take two hours, it takes a day or two.
This is pretty tough: You always thought of yourself as an über-geek, capable of chewing out hundreds of lines per hour. Now you see that you need a day for a puny little class. How humiliating. And your colleagues tell you that they do it in two hours.
That’s the point where developers invent the “double-and-add-some” method, or the “developer factor”, or something like that. The idea is always the same: You can still pretend that writing the class takes two hours – if “everything goes right”. But since something always goes wrong, the job takes twice as long as planned. The “developer factor” accounts for those mysterious forces, that mess with your project. But if heaven hadn’t conspired against you, you could have been really fast.
This approach has several psychological advantages: Making time estimates is easy, because you don’t have to think about possible problems. You can pretend you’re twice as fast as you really are. And, best of all, deadlines don’t look as bad any more: When you’re out of schedule, just pretend that the time for the remaining work can be cut in half “if nothing goes wrong”.
This kind of schedule will fail. You may feel good about it, but it will still fail. Even if your estimate is correct, you’ll never know until the project is over. And if you’re running into problems, you’ll never know until it is too late.
A proper schedule is a set of tasks and estimates. If it is honest, it will tell you that you’re only mortal (unless, of course, you’re not). But it will also tell you if your project is still on track, if you have to adjust your estimates or cull features. If you run into trouble, you’ll have warning ahead of time. It’s really like taking the rubbish out: Either you do it now, your you’ll have to live with the stench.
If you want to know why schedules are good for you, and find a reasonable easy way to do one, you could start with Joel’s suggestions.