The benefits and harm of deadlines in programming
I often find myself thinking that the presence of time when writing software can have a negative effect, although many believe that time is useful. It seems to me that they need to be applied with caution after all (like any other pill of happiness). I tried to analyze how deadlines can harm a project, and how deadlines can improve a future result.
For those who are too lazy to read the whole article: I believe that deadlines are needed, but managers and programmers should understand that deadlines sometimes fail, and that there is no big tragedy in this. Sometimes in failed terms, circumstances are to blame, rather than specific people.
Having deadlines for the things you do is useful. But in the case of programming, there are some nuances.
How do terms help writing software?
')
Thanks to the timing you can plan the future. If we plan to finish work on features X in 2 months, then we know that in 3 months we can release a new version of our software.
Timing helps with rationalization / optimization: if we know that in terms of time, Peter finishes working on features X in 2 months, and Vasya finishes working on his task after 2 days, then it is easier for us to find out who has a lot of work. If tomorrow there will be some kind of medium importance bug, then we will be able to rationally weigh the situation, and decide that we will fix this bug to Vasya, who will be free in 2 days.
Deadlines can also act as an additional way to specify the task. The programmer can maneuver under the influence of the timing - somewhere he will be more zealous and clean, and somewhere he will not. And this is good, because due to such maneuvers, ultimately the speed of software development will increase.
How do terms prevent you from writing good software?
Unfortunately, programming is a complicated thing, and even good specialists cannot calculate the time in advance. In addition, most programmers estimate the timeline overly optimistic. Therefore, deadlines are often overdue. It turns out that the programmer needs to invest a lot of emotions and efforts in order to complete some task in the stipulated time frame. A programmer may call unreasonably optimistic terms under pressure from managers. Even worse, when managers themselves call deadlines to programmers.
Timing in the eyes of many programmers is a punitive-reproachful tool for managers. For such programmers, terms cause some emotional discomfort. When a programmer is ill at the emotional level, then most likely his effectiveness will decrease.
When the programmer sees that he does not have time to close the task in the necessary time, he will work with increased diligence and increased concentration. I see 2 implications of this:
In the end, the programmer will think “ What is my fault? Why should I now put extra effort into my work? Just because I misjudged the timing? ". With such thoughts, any person will very quickly lose motivation for his work.
Who is to blame? And how to save the situation?
As usual, the truth is somewhere in the middle between the manager and the programmer. From the manager’s side, I would:
If I were a programmer, then I would:
Moral and distribution of prizes
Guilty and right there in this situation. If the quality or speed of software development falls due to the deadline policy in the company, then both are to blame. Terms need to use and useful. But it seems to me that the deadlines should be mild - the employees should understand that they should “fail” the deadline, if otherwise they would have written crutches or if otherwise they would have exhausted themselves emotionally. We are still not clairvoyants, and the dates will always be inaccurate, so you need to be open to the fact that the dates can be adjusted.
For those who are too lazy to read the whole article: I believe that deadlines are needed, but managers and programmers should understand that deadlines sometimes fail, and that there is no big tragedy in this. Sometimes in failed terms, circumstances are to blame, rather than specific people.
Having deadlines for the things you do is useful. But in the case of programming, there are some nuances.
How do terms help writing software?
')
Thanks to the timing you can plan the future. If we plan to finish work on features X in 2 months, then we know that in 3 months we can release a new version of our software.
Timing helps with rationalization / optimization: if we know that in terms of time, Peter finishes working on features X in 2 months, and Vasya finishes working on his task after 2 days, then it is easier for us to find out who has a lot of work. If tomorrow there will be some kind of medium importance bug, then we will be able to rationally weigh the situation, and decide that we will fix this bug to Vasya, who will be free in 2 days.
Deadlines can also act as an additional way to specify the task. The programmer can maneuver under the influence of the timing - somewhere he will be more zealous and clean, and somewhere he will not. And this is good, because due to such maneuvers, ultimately the speed of software development will increase.
How do terms prevent you from writing good software?
Unfortunately, programming is a complicated thing, and even good specialists cannot calculate the time in advance. In addition, most programmers estimate the timeline overly optimistic. Therefore, deadlines are often overdue. It turns out that the programmer needs to invest a lot of emotions and efforts in order to complete some task in the stipulated time frame. A programmer may call unreasonably optimistic terms under pressure from managers. Even worse, when managers themselves call deadlines to programmers.
Timing in the eyes of many programmers is a punitive-reproachful tool for managers. For such programmers, terms cause some emotional discomfort. When a programmer is ill at the emotional level, then most likely his effectiveness will decrease.
When the programmer sees that he does not have time to close the task in the necessary time, he will work with increased diligence and increased concentration. I see 2 implications of this:
- Decreased operational maneuverability of the programmer. If he knows that he damn lags behind in some task, then he will take a more passive position in the general life of the working team - he will stop helping newcomers, will be dismissed by the first decision that comes to mind when you need to discuss some future architecture. If several people work on the “overdue” task, then it is very likely that each of them will begin to shift responsibility from one to another, since they simply will not have time to take the initiative in their own hands and coordinate the overall interaction.
- A programmer, like any other person, gets tired. If, on average, he wrote 50 kg of a beautiful code, then under the pressure of the deadlines, he will start writing 75 kg of a beautiful code. But it won't last forever, he will either start writing 75 kg of an ugly code, or sooner or later he will “roll back” back to his standard productivity of 50 kg of beautiful code. And immediately after the delivery of this overdue task, he will rather roll back to the negative side - at least for the first few days he will write only 30-40 kg of beautiful code.
In the end, the programmer will think “ What is my fault? Why should I now put extra effort into my work? Just because I misjudged the timing? ". With such thoughts, any person will very quickly lose motivation for his work.
Who is to blame? And how to save the situation?
As usual, the truth is somewhere in the middle between the manager and the programmer. From the manager’s side, I would:
- Allowed the programmer to call his own deadlines (if this is not the case for us yet). If I see that the programmer is feeling pressure from my side and trying to call the deadlines too fast, then I would try to remove this pressure - why should I programmer who calls the wrong dates at my sight?
- Followed the validity of the terms (thanks ncix ). If the programmer answers my question about deadlines, “Ah, in a month it will be done.” Then I would ask the programmer to show me how in a month he plans to do this, into which sub-steps he will break the work. How quickly he expects to complete each of the sub-steps.
- Established emotional understanding with the programmer.
- The programmer will then not feel depressed if he has a “stuck” task. He will simply go to the manager and say: “Stepanich, I don’t have time so and so ... What are we doing? Give extra resources to the task or postpone the date? "
- The programmer will disappear guilty for failure to meet deadlines, and he will be more outspoken with the manager. Deadlines will no longer be a punitive tool manager in the eyes of the programmer.
- How should I follow the honesty and fairness in the team. Since I offer a high level of trust and freedom in relation to programmers, then there may be such programmers who try to derive benefit from this in a roundabout way. Such programmers should be excluded from the team, because they undermine morality.
If I were a programmer, then I would:
- He also developed an emotional understanding with his manager. I don’t want to come to the manager tomorrow and say “Stepanych, I don’t have time ...”, and I’m afraid that Stepanych will consider me lazy.
- I would not give a weakness: when they ask about the dates and their faces it is clear that they need it tomorrow, I would try not to give in to emotional pressure and would appreciate soberly the amount of work.
Moral and distribution of prizes
Guilty and right there in this situation. If the quality or speed of software development falls due to the deadline policy in the company, then both are to blame. Terms need to use and useful. But it seems to me that the deadlines should be mild - the employees should understand that they should “fail” the deadline, if otherwise they would have written crutches or if otherwise they would have exhausted themselves emotionally. We are still not clairvoyants, and the dates will always be inaccurate, so you need to be open to the fact that the dates can be adjusted.
Source: https://habr.com/ru/post/244309/
All Articles