[noonat]

Programmers are often asked to accurately estimate tasks that are too large to estimate. The smaller or larger the task, the more likely it is that there will be errors in the estimate. The larger a task, the more likely there is a detail that has been missed during estimation, the more chance that you will encounter a surprise during development that greatly increases development time.

Most successful estimation methods boil down to refusing the estimate larger tasks, and instead breaking them down into smaller tasks. The process of breaking them down forces people to think through them in more detail, and you flush out many of the surprises early on. Similarly, most of the successful systems require you to apply a minimum amount of time per task (e.g. one hour). This removes the problem of programmers underestimating simple tasks.

The best estimates come when you continue to use that system over several iterations of work, and analyze the accuracy of previous estimates. This gives you (and other developers) a better sense of how to make good estimates.

Sadly, even when you have a reliable system of predicting how much work a development team can get done in a given chunk of time, many managers bow to pressure from above to hit deadlines, and expect the team to accomplish more than the data says they are able to accomplish.

[roc]

I would add that the only really good estimates happen when a small task is estimated by a programmer who has already performed that task, at the same level of complexity, a few times before. (And the programmer doing the estimating is the one who'll be doing the implementing, natch.)

Even at the scale of small tasks, programmers estimating things they've never done before are often wildly wrong.

[HeyLaughingBoy]

You are correct, but note that a wildly wrong estimate provided with good intentions is better than no estimate at all.

If I get an estimate for something that's never been done, I want to know that it's a SWAG so I can rate it accordingly. If you go ahead with the task, I'd probably ask you to give me more frequent updates than normal, so we can see if the estimate needs to be adjusted.

I know that a lot of people work for hugely disfunctional organizations, but in most reasonable places, it's expected that some estimates will be wrong and either the task should be killed, or the schedule adjusted.

[roc]

Oh absolutely. It's like that old chestnut about plans being useless but planning being essential.

And one can even find productive use for an aggregate SWAG-to-reality ratio, tracked over time. Individually, that ratio won't give you any better an indication on where a given SWAG is likely to land, but in the aggregate you can use the ratio to put something like error-bars on the project as a whole.