[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.