First solution I've heard was from my professor at University - it boiled down to "take your best estimate then multiply by 3". Needless to say, I thought that as overly cynical view of life until I started working :)
What happened next was that I either worked in companies that didn't really asked for estimates, just for job done in order of priority, with appreciation on faster the better, or I had to give estimate to project manager, in which case neither of us really knew what's the problem is. Me, because at that point I didn't have enough information to understand the whole problem, project manager because it was not their job to understand technical problem, just to manage resources and timelines. And in those cases I rarely had a chance to revise my estimates based on improved understanding, so above mentioned maxim was very useful when I finally started to see the wisdom in it.
Second time I really had to think about way I estimate thing was on the interview. Question was about guessing how many golf balls will fit into school bus. It was not fun, since I had no idea how big actual school bus is! I did look it up, and BTW, maximum length is 12.5 meters = 40ft.
After some discussion, it turned out that interviewer wasn't really interested in the anything but the estimation process. He explained that basically, you start with arbitrary number that you know is wrong - i.e. bus is less than 1 yard (or meter) long. Since you know it's wrong, you go to the other end - bus is longer than 15 yards (meters). Well, wrong again. So your length of the bus is average of those 2 - that's the answer. Even if this is more than actual bus length (or less), whatever, that's your starting point of estimate.
It will take less than a day? Wrong. It will take more than a week? Wrong. Ok it will take 2-3 days then.
That interview didn't work out in the end, unfortunately, since what they really needed was Web Forms person, not MVC specialist like me, but it was fun and challenging interview.
Today I've found this table at http://coding.abel.nu/2012/06/programmer-time-translation-table/
| Estimate | The Programmer Thinks | What the Programmer Forgot | Actual Time |
|---|---|---|---|
| 30 seconds | There’s just a small change to the code to be done. I know exactly what to type and where. It takes 30 seconds to type. | Time for starting the computer, the development environment and getting the right source. The time to build, test, check in and document the fix | 1 hour |
| 5 minutes | It’s a minor thing, I just have to look up the exact syntax on google and fix it. | It’s quite rare to find exactly the right information on the first try. Even if it is found, it probably needs some adjustments before it works. Add time for building, testing etc. | 2 hours |
| 1 hour | I know how to do it, but it’s some code to write so it will take some time. | 1 hour is too tight to have any margin for unforeseen problems. Something always fails. | 2 hours |
| 4 hours | It’s some code to write, but I roughly know the step. I know the Wizzabanga module of our standard framework can do it, but I have to check the documentation on exactly how to call it. | This is probably the only realistic estimation. It is large enough to have some margin for unexpected problems, while the task is still small enough to grasp. | 4 hours |
| 8 hours | I first have to refactor the Balunga class into two, then I’ll add a call to the Wizzabanga code and finally add the new fields to the GUI | There’s a lot of dependencies on the Balunga class from different parts of the system. About 40 different files have to be adjusted. The newly added field in the GUI has to be added in the database as well. 8 hours is too large to grasp completely. There will be more steps than the programmer thought of when estimating. | 12-16 hours |
| 2 days | It’s really quite a lot to code. I have to add some new tables to the database, a GUI for those and then the logic to read and write data to the tables. | 2 days of work is too large to overview for most developers. There will surely be things that are missed. Not just small things, but entire major pieces of functionality required will be forgotten during the estimation. | 5 days |
| 1 week | Ouch… that’s a HUGE task. I don’t have a clue on how to do it, but I can’t say I don’t know. One week should be enough, I hope, I really hope, but I can’t ask for more or they’ll think I’m not competent enough. | The task is way too large to get an understanding of for most programmers. It has to be sent back to an architect that can help splitting it in smaller parts and provide some direction how it should be solved. The architect might find a simple way to do it – or find that there’s a lot more work than expected. | 2-20 day |
