Why programmers underestimate timing
In today's world time - it is the most expensive and in demand resource. Everyone wants to know the exact term, everyone wants this period to be as short as possible, and the result is as good as possible. Custom software development is no exception.
The well-known joke "Ask the programmer about the term and multiply the answer by π" has a number of serious reasons. In this article we will try to understand why the developers underestimate terms and how to help them achieve a realistic timing.
How many time will it take to read a 300 pages book? 3-4 hours? Yes it will, but only if at this moment your girlfriend doesn't call you, or you do not want to have a bite, or your neighbor does not make noisy repairs. So many "ifs" for such a simple task like reading a book. Programmers' tasks, in turn, require a truly immersive and any distractions make them spend time for returning to the world of abstract entities. So, the first reason for low time estimates: people tend to operate "ideal hours".
Let's go back to reading the book. You were reading for 1 hour when you wanted to sleep. Perhaps yesterday you celebrated a birthday or your blood pressure dropped. But the fact remains the same, your productivity suddenly fell and reading speed fell along with it. Reality does not spare us and we physically can not have perfect state and mood 24/7. Herein lies the cause for the second reason for low time estimates: we think that our working efficiency is always at a high level.
It is difficult to imagine that someone would plan their time in the following way: "Well, I have a task. While executing, I will make one large mistake and two small. Then I will fix a big mistake and send the task for testing. A tester will find two small errors and I will fix them as well". However, unfortunately, in real development process such situation is not rare. The third reason for low time estimates: we expect to get a perfect result without the need for corrections and improvements.
Of course, apart from all mentioned reasons, we have in mind that the tasks themselves are made up perfectly, they do not have "branching" (when one task is suddenly divided into several related), and the requirements spelled out clearly and unambiguously. Otherwise, you should take into consideration the time required for clarification and formalization of the task.
As you can see from our example with the reading of the book, time underestimation is not the prerogative of programmers - it is a common human trait. Competent project manager will take into account our psychological characteristics and adjust the terms accordingly.
