An experienced project manager I once worked with claimed that when he got the programmer's time estimate, he multiplied it by π, and then converted it to the next order of magnitude to get the real value. 1 day translates to 3.14 weeks. He has suffered in the past because programmers are not good at estimating time. I created a table for translating programmer time estimates to minimize estimation errors.
Difficulty in time estimation. Every programmer has a realistic estimation interval. Estimates below this range mean that the time overhead (of building, testing, and reviewing the code) is underestimated. An estimate outside this interval means that the task is too large to estimate.
For junior developers, this range doesn't even exist. They ignore the time overhead (of building, testing, checking the code), and they can't predict difficult tasks. I'd say an experienced developer should get things done in 0.5 to 24 hours. More than 24 hours, you need to subdivide. This work should be done in the developer's head and then add up to 60 hours. But even some experienced developers need to think about using management time blocks.
It's also important to understand: programming experience is not the same as estimating experience. A developer who is not included in the estimation process will not be good at estimation. Likewise, if the actual time spent is not measured and used to compare with estimates, there will be no feedback to learn.
Finally, every programmer should have the skill to estimate. To hone this skill, decide what you're going to do as you take on each task. Then estimate how long the task will take before starting. Finally measure the actual time spent and compare with the estimate. Also compare what you actually accomplished with what you planned to accomplish. This way you will improve both your understanding of the details a task contains and your estimation skills as well.
Source: http://www.oschina.net/news/31646/programmers-are-bad-estimating