Estimation of task execution time

    Working on a large, constantly developing project, I deal with various forms of task approval almost daily: from “Very urgent, correct it here. Can you keep up with the hour? ”To“ Estimate how many weeks this task will last. ” I, as a performer, myself evaluate the time and complexity of each task and consider it the only right approach to assessing the front of upcoming work in the field of software development.

    But, watching many projects - third-party, which are written about in articles and blogs, as well as projects of neighboring departments of the company, I see that different project managers use different approaches to assessing the timing of tasks. And they do not always coincide with my attitude to this matter.


    Summarizing the information accumulated on the topic of estimating deadlines, I received the following principles for assessing the timing of work:

    • The final assessment of the task can only be given by the immediate executor;
    • Time estimates are always too optimistic;
    • It is impossible to estimate the whole time for a task requiring splitting into subtasks.

    Observing these principles, the light at the end of the tunnel becomes visible even to the first line of code. The direct executor (or executors, in the case of group development) itself breaks down the general task into subtasks for a more accurate assessment and indicates the risks for each of the subtasks. Thus, by adding time to each of the subtasks, you can get very optimistic deadlines for the entire amount of work. These terms are multiplied by risks and the approximate time required for the entire work is obtained. The main thing is that not only the performer but also the customer understands these principles, otherwise he will want to play a “guessing game” with the performer.

    Guessing game

    In the process of completing a task, circumstances may arise that require additional time to resolve. For example, it turns out that the system architecture does not allow you to solve the problem “quickly and beautifully”, and the development team has to choose: do hacks and a lot of other unnecessary work that aggravates the state of the system as a whole, or invite the project leader to refactor the necessary modules.

    Both solutions are obvious, as well as the fact that the second is more acceptable in the long run. The complexity of the situation is that some decision-makers think that everyone in the company plays a "guessing game": once a programmer has named a deadline, he has to keep within it. And he does not care about the changed circumstances, it is more important for him to “shove off” the responsibility for the terms of the contractor than to try to find the optimal solution to the general problem.

    Individual approach

    Almost every project has its own architecture and its own heritage (usually “heavy”), therefore, when evaluating a task, it is reasonable to make an adjustment for the specificity of the project. It’s one thing when the project is young, thought out, and the code is written with meticulous observance of all the norms and rules of design and coding, and it’s quite another thing when the project is in continuous development for already 5 years, for which dozens of developers have replaced, having written hundreds of thousands of lines of code using the “ if only it worked. ”

    The more confusing the architecture and the messy the existing code, the greater the risk of not meeting the deadlines. In such cases, I see a solution in entering special coefficients by which the preliminary estimate of the time by the problem is multiplied.

    Mind games

    No matter how much experience a person setting a task has for a developer, he can only "estimate" the timing of its implementation, too many nuances must be taken into account in each specific case: is this new functionality or refinement of an existing one, the flexibility of the system architecture and the quality of the existing code, the specific approach to solving a problem within a specific project.

    And if the task manager does not have a technical background, he can only guess the timing of the task. And he can do this only out of curiosity - he will guess or not, because such an assessment does not have practical value.

    The thing is that some project managers are trying to personally set deadlines for the programmer to perform a specific task, which is basically absurd. The roots of this ignorance come from a lack of understanding of the specifics of working in the IT field: only the system administrator can estimate the time for which he will configure the server, and only the programmer can tell the time that will be spent on the task. The manager’s job is to manage tasks, but the processes inside the task are no longer in his competence.


    There are a number of tasks that should include the ability to transfer functionality to other projects. If the company has several projects and the estimated task must be completed within each of them, it is time to review the assessment of the timing and complexity of this task.

    First, the requirement of “universality” should be stated immediately, and not after the task has already entered the implementation stage. If the customer wants to make the functionality universal at one of the later stages of development, this will lead to a rewriting of a considerable part of the code, and therefore to a revision of the terms.

    In my practice, there was a case when, at the end of a complex mechanism for one of the projects, the customer wanted to use it on another project and, having received an answer about the specificity of the task, complained that the functionality was not universal. But this is a difficult case ...

    Hard case

    I would also like to mention cases when the task manager (customer) considers himself a professional, although in fact he does not even pretend to be. Such a customer does not believe in anything outlined in this article and believes that he is able to estimate the deadlines of the task himself up to a minute, even without enough technical knowledge.

    It is better to abandon cases with such tyranny. This is the best way out for everyone: the contractor gets rid of unrealistic deadlines, the customer, after countless attempts, still dies his “professionalism”.


    In my memory, there was a case when the management wanted to “freeze” one sluggish and absolutely unprofitable project, after some refinement of the functionality. The programmers were asked to evaluate the task, they evaluated it without risk - they gave a very optimistic, minimal time frame. When they started digging, they realized that they were in serious refactoring. After sleepless nights in the office and work on Saturdays and Sundays, the deadlines were met in the end, but with slight imperfections. For these imperfections, a verdict followed from the authorities: the programmers broke the terms they named. There is a game of "guessing", no one wanted to hear about any risks.

    The programmers themselves set themselves up, as a result they were additionally accused of losing the project and sloppiness, but the management itself looked good at the meeting with the investor, blaming the loss-making project on the disorder of the development team.

    Also popular now: