Why is it difficult for programmers to evaluate development time?

A seasoned project manager who once worked with me "http://www.aliyun.com/zixun/aggregation/6918.html" claims that after he gets the programmer's time estimate, he multiplies it by PI and then transforms the next order of magnitude To get the real value. 1 days into 3.14 weeks. He used to suffer because programmers were not good at estimating time. I created a table to translate programmer time estimates to minimize the estimation errors.

Time estimates are difficult. Every programmer has a realistic range of estimates. An estimate below this interval means that the time overhead (component, test, check code) is underestimated. An estimate over this range means the task is too big to predict.

This interval does not even exist for primary developers. They ignore the time overhead of (component, test, check code) and difficult tasks that they cannot predict. I want to say that 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 mind and then combined into 60 hours. But even some experienced developers need to use management time blocks to think.

It is also important to understand that programming experience is not equivalent to estimating experience. A developer who is not included in the estimation process will not be good at estimating. Similarly, if the actual time spent is not measured and compared to the estimate, there will be no feedback to learn.

Finally, every programmer should have the ability to estimate. To hone this skill and take on each task, decide what you want to do first. Then estimate the time required for the task before you start. Finally, the actual time spent is measured and compared with the estimate. Also compare what you actually accomplished with the planned completion. This will improve your understanding of the details of a task, as well as your estimation skills.

SOURCE Link: Programmer time translation cheatsheet-or-why programmers Are