It’s a rule of thumb that terms of implementation which are given by developers should be multiplied roughly by 3 in order to receive more accurate and probable estimation. I always wonder why this rule works and what common mistakes are done by programmers so they almost always are wrong by the same amount of time?
First of all, let us discuss what programmers take into consideration to make their estimates. As one of them, I could contend that engineers are interested primarily in developing. Regarding that, they think only about the technical implementation of the solution and they don’t consider about other aspects and activities that are needed to bring the code to production. So programmers’ estimates show only the time that is required to write necessary code.
However, before the time the code could solve the business problem obviously it should be built, tested, and deployed to the production stage. These steps are often united into “integration” activity. It could also involve other actions such as updating production environment, releasing other parts of the system what developed functionality depends on, and so on. Depending overall complexity if the existing system, integration may take as much time as it is needed for coding. So we already have multiplicator of two.
Another assumption that is made by programmers and significantly reduces estimated time is that all requirements were fully gathered and they won’t be changed while developing. I think this assumption comes due to introvert nature of software engineers and their unwillingness to communicate with other team members. They forget that interactions within a team are very important, even vital, for bringing values to the company. That is one of the reasons why big companies such as Google, Facebook, Amazon, and etc. are ready to pay a lot of money for a needless project just to occur a well-functioning team.
Back to our topic, it’s a rare situation when all prerequisite work is done before the start of the implementation. Inevitably programmers need to clarify the task, conform documentation and do other things to make sure that the task is well understood. Sometimes in order to implement the task, some changes in other parts of the system (controlled by other teams, for example) are required. All these activities cannot be done without communication that makes pain to developers. Here we have found another piece of time and come to the value of multiplicator of three.
All others unexpected and unpredictable events such as developers’ illness or bad mood would not exceed 0.14 of overall time.
To summarize, if you need to give the accurate estimate of the work you should consider the fact that preparation and release work is not less important and each one could take as much time as the main implementation task.