Why cannot developers accurately assess the project time?

An experienced project manager who once worked with me claimed that after obtaining the programmer's time estimation, he first multiplied it by π and then converted it to the next time order of magnitude, to get the true value. 1 day is converted to 3.14 weeks. He used to suffer from poor time estimation for programmers. I created a table for translating programmer time estimates to minimize estimation errors.

Time Estimation is difficult. Every programmer has a realistic estimation interval. Estimation below this interval means that the time overhead (component, test, check Code) is underestimated. The estimation that exceeds this range means that this task is too large to be estimated.

For novice developers, this interval does not even exist. They ignore (component, test, check code) time overhead, while difficult tasks are unpredictable. I would like to say that an experienced developer should finish the work within 0.5 to 24 hours. More than 24 hours, you need to subdivide. This should be done in the developer's mind, and then the total is 60 hours. However, even some experienced developers need to consider using management time blocks.

It is equally important to understand that programming experience is not the same as estimation experience. A developer not included in the estimation process will not be good at estimation. Similarly, if the actual time spent is not measured and used for comparison with estimation, no feedback is provided for learning.

Finally, every programmer should have the estimation skills. To Hone this skill and take over each task, decide what you want to do first. Then estimate the time required for the task before it starts. Finally, measure the actual time spent and compare it with the estimation. Compare what you actually completed with what you planned to do. In this way, you will not only improve your understanding of the details of a task, but also improve your estimation skills.