Programmer's time exchange table -- Why programmers are not good at estimating time

Original article: programmer time translation cheatsheet-or-Why programmers are bad at estimating times

Http://www.ituring.com.cn/article/details/8290.

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.

Estimated time	What Programmers think	What programmers forget	Actual Time
30 seconds	You only need to make a small code change. I know exactly how to change and where to change it. It takes 30 seconds to press the keyboard.	Start the computer, develop the environment, and obtain the correct source code. Time used for component, test, check, and document repair.	1 hour
5 minutes	I just need to check the syntax on Google to fix it.	The correct information is rarely found once. Make some adjustments even if you find it. Additional components, testing, and so on.	2 hours
1 hour	I know how to do it, but it takes some time to write the code.	In the face of possible problems in the future, one hour is fleeting. Something always goes wrong.	2 hours
4 hours	I need to write some code, but I have a rough idea of the steps. I know that the wizzabanga module in the standard framework can do this, but I have to check the documentation to learn how to call it accurately.	This is probably the only realistic estimation. It leaves plenty of room for unexpected errors, and the task is small enough to grasp.	4 hours
8 hours	First, I need to re-construct two balunga classes, then add a call to the wizzabanga module, and finally add some fields to the GUI.	There will always be many different parts of the system dependent on the balunga class. There are about 40 different files to be modified. The newly added fields for the GUI also need to be added to the database. 8 hours is too long to be fully grasped. There will always be more steps than the programmer estimates.	12-16 hours
2 days	There is really a lot of code to write. I need to add some new tables to the database, display the table GUI, and read and write table code logic.	For most developers, the workload in the past two days has become hard to estimate. Something is missing. It is not just a few small things, but a large part of the main functions will be forgotten in estimation.	5 days
1 week	Alas, this is really a tough task. Although I have no idea, 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 will think that I am not competent enough.	This task is more than most programmers can understand. It should be sent back to the architect to help divide it into smaller parts, and then provide some directions to solve the problem. Architects may find a simpler way to complete it, or discover more jobs beyond imagination...	2-20 days

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.