Why Can't Developers Estimate Time?

Ohhh, my bad, I totally forgot that people like selling things that don't exist but telling everyone else they do exist.

> The good news for both developers and managers is that estimation is a learnable skill. If you get in the habit of making estimates and testing them, you'll get better amazingly fast.

To an extent, though, the better you are at programming, the worse you'll be at estimating.

A bad programmer, given a one-week task similar to one he's done before (when it took him two and a half weeks), will estimate it at two weeks and do it in two weeks, plus or minus a bit.

A good programmer given the same task will try to apply the previous solution, or use a library that solves the problem, and usually get it done in two to four hours. But some of the time that won't work, and then they will spend three days doing what would have taken the bad programmer two weeks, and a fourth day generalizing it so that when they have to do a similar task the third time, they can do it in two to four hours.

The good programmer's estimate will, therefore, frequently be off by a factor of ten or more.

In short, the better you are at automating what you've previously done, the more time you spend doing things you haven't done before, and so the more uncertain your estimates are.

The central limit theorem says that if you add up enough independent random variables from whatever distribution, their sum will eventually start to look like a Gaussian normal distribution. Unfortunately, this isn't as useful as you might think for software project estimation, both because different tasks aren't independent and because when the underlying distribution is heavy-tailed (e.g. lognormal, exponential, etc.) "enough variables" can be much larger than the number of tasks in your project: in the hundreds or thousands.

> If you asked a developer to estimate how long it would take to hand write a class for every HTTP status code in v1.1 of the standard (and gave them a copy of the standard), they could probably give you an accurate figure.

Yes, but that's explicitly demanding that they write the software incompetently. Writing software incompetently, by mechanically carrying out actions that ought to be automated, is easy to estimate. But if I thought I needed a Java class for each HTTP/1.1 status code, I'd write a Perl script to generate them, be done in a tiny fraction of the time, and have a vastly more maintainable codebase.

Your other point about multiple stakeholders is well taken, of course. But even when it comes to solving a well-defined problem, it's easy to misestimate by orders of magnitude.

You're right that managers who understand your job can make life a lot easier. But this goes both ways. I find that understanding what constraints my management is under can help me to help them plan.

When you understand what their problem is (e.g. we promised X to the client and we have to make it work somehow), you might be able to rearrange things to make that possible. Of course, an ounce of prevention is worth a pound of cure: if you can help them avoid promising the impossible, you'll be a lot better off. Otherwise, you end up suffering due to arbitrary deadlines created for the sake of looking good. If you can find better ways for your boss to look good than impossible deadlines, you'll be way ahead. I grant, though, much of this is easier said than done.

What's needed may just be to solicit a wide confidence interval (e.g. "this task will take between 20 minutes and 1 month, and I'm right 90% of the time recently when making such estimates"). You can drop the lower-bound part, probably.

People absolutely should be able to provide a rough estimated amount of effort for a task. The trouble is in using a single point to describe the whole probability distribution. You may be right, in that nobody seems to have a great way of soliciting a probability distribution (or even a single probability) that makes sense. Something like a 70% confidence interval bracketing the amount of effort would be useful, but not sufficient.

I also agree that even if people could describe their beliefs about the required effort rigorously, you have to wonder how much planning/analysis they should spend trying to come up with a tight estimate. An 'outside view' - http://wiki.lesswrong.com/wiki/Outside_view - could give something reasonable in cases that aren't too novel.

I think estimates will never become useless. It's just that we may decide to replace them with "time by which we'll be late only 1/6 of the time", and provide feedback and incentives for people to correct this estimate so that it's, for someone who's experienced in the domain, eventually relatively unbiased.