Kirk: “How long to re-fit?”
Scotty: “Eight weeks. But you don’t have eight weeks, so I’ll do it for you in two.”
Kirk: “Do you always multiply your repair estimates by a factor of four?”
Scotty: “How else to maintain my reputation as a miracle worker?”
Kirk: “Your reputation is safe with me.”
– From Star Trek III

I started this post awhile back with the idea of advocating Scotty’s “miracle worker” method of work estimates. In a nutshell, Scotty’s approach is to under-promise, over-deliver. On the surface, this sounds like a great idea. If you constantly pad your estimates, it gives you lots of wiggle-room when things inevitably go wrong, and it means that if the project takes the amount of time you thought, you look like a hero.

Scotty: “Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.”
Geordi: “Yeah, well, I told the captain I’d have this analysis done in an hour.”
Scotty: “How long will it really take?”
Geordi: “An hour.”
Scotty: “You didn’t tell him now long it would really take, did you?”
Geordi: “Of course I did.”
Scotty: “Laddie, you got a lot to learn if you want people to think of you as a miracle worker!”
– From the Next Generation episode “Relics”

However, when I somewhat-jokingly mentioned this blog post to my boss, he got really uncomfortable. I decided to put a little more thought into this post, and quickly stumbled across a few problems with the theory. First of all, it only works if you’re giving your estimates directly to the client. If you report to a project manager, you quickly end up with a snowball effect:

Recently I got asked “How long to add this link to our web site” (or something equally trivial). In my head I went, “Um, like, ah, Five Minutes”. Then I went, “…but, I’m not going to have a spare five minutes this week, and it’s five minutes to add the link, but it’s also ten minutes just to open visual studio, and five minutes to test locally, and five minutes to fix the typo/spelling mistake, and then thirty minutes to do a build, and thirty minutes to get it into the staging system, then a little wait to have the customer confirm that it’s OK, then thirty minutes to get it into production”. So… it’ll probably knock out most of a day. But, if I think it’s actually going to take a day, then I should say a week, because I’m demonstrably always overly optimistic. Besides, at least a week will *pass* (while I’m not working on it) before I get the opportunity to even look at it. So I say “Look, it’s pretty easy. It’ll take five minutes to add the link. A day to get it into production. Say a week.”

Then the manager gets my estimate, and knows that he should treat me as being too optimistic, so he hears a week and doubles it. Then he tells the customer that it will take at least two weeks.

The customer hears that it will take two weeks to add a link, and they think “There is *no way* we’re going to pay for that”, so they cancel their ‘order’, then they cancel their account, and the whole system functioned to lose business.
– John, from a thread about project estimates

The best advice I’ve found on the subject is to learn from your past, as Scott Hanselman recommends. Basically, start tracking your estimates. Make notes about what type of work you did, and whether you came in over or under. Over time, you’ll get a better idea of how to adjust your estimates to be more accurate. This is certainly something I need to work on, and my goal is to start keeping a record of all the estimates that I give along with the final results.

Of course, this only addresses estimates you make yourself. If your initial estimate was provided by a project manager, and you were never given a chance to address it, there’s not a lot you can do.