[Clubber]

It really depends on how you define bad at estimating. I can tell if something will take a few hours or a few days pretty reliably, but not down to the second. The trick is to include all the friction into the estimate (test, deploy, potential collateral damage, random pings from biz or devs, etc) then add 30% for oops factor. It's much better to be early and overestimate than be late, particularly when there are dependencies on your completing on time. The more you know a codebase, the better at estimates you are of course.

This all falls apart without a good tight spec. If the spec is loosy-goosy, then forgetaboutit.

[commandlinefan]

> This all falls apart without a good tight spec

Maybe I've had 30 years of bad luck, but I've never seen a "good tight spec" since I started programming professionally in 1992. Most of the time there's no "spec" at all.

Even if you do manage to get the estimate-demanders to back off until the spec is good and tight, you're just moving the problem upstream - they'll just want an estimate on how long it will take to get the spec right.

[Clubber]

Ya that's a lot of bad luck or maybe it's just the industry you work in. I've worked (and currently work) at departments that require it from biz. We can send it back for refinement too, or just pick up the phone and ask questions, etc.

>they'll just want an estimate on how long it will take to get the spec right.

The people who want the estimates are the same people responsible for the spec, so you're actually pushing the problem onto where it belongs.