Software Engineering Deadlines: Benefits and Disadvantages

I found myself thinking that existing schedules in software development can give negative effect. Nevertheless more people still insist that schedules play a positive role. I think it’s necessary to apply it with care (just like any other «Silver bullet» for software development). I’ve tried to analyze how schedules can ruin the project and how it’s possible to improve future results.

spectrum1031.com

I believe that schedules are necessary, but managers and programmers need to understand that people sometimes are failed with deadlines and there is no big tragedy. Sometimes circumstances, not people are the reason of failed deadlines.

It’s useful to meet deadlines for the things you are doing, however there are some nuances in case of programming.

How deadlines can be helpful

Due to schedules you can plan your future work. If we plan to finish our work on the item “X” during 2 months, then we know that after 3 months we’ll be able to release a new version of software.

Schedules are very helpful with rationalization and optimization: if we know that Peter will finalize the item “X” in 2 months, and Bob will make it in 2 days, then it is easier to sort out who is busier. If tomorrow we will find a bug with medium importance, so we can rationally weigh up the situation and assign this bug fix to Bob, because he’ll be free in 2 days.

Schedules can also act as an additional method of task specification. Programmer can maneuver under the influence of schedules, somewhere he will be more diligent but somewhere he will not. And that is good, ‘cause the ultimate speed of software development will grow due to such maneuvers.

How shedules influence on software development

Unfortunately, programming is a difficult thing and even the experts sometimes cannot calculate right schedules in advance. In addition, majority of programmers estimate the duration of development in too optimistic way. So often experts don’t meet the prescribed deadlines. It turns out that programmer need to put a lot of emotions and efforts in order to complete some task on time. The programmer can designate unreasonably optimistic deadlines under managers’ pressure. Even worse, when managers are trying to set up deadlines to programmers.

Deadlines are some kind of punitive, reproaches managers’ tools in the eyes of many programmers. This can be the reason of emotional discomfort. Reduced effectiveness due to low emotional level is the main problem.

When the programmer realized that he cannot finish the task in time, then he’ll try to increase zeal and concentration. But however this might lead to the following:

• Reduced programmers’ operational agility. If he knows that he’s falling behind, than he’ll take a passive role in working process. He stops helping the beginners and choose every first decision which comes to his mind, when you need to discuss some future architecture. If there are few people are working on overdue task, it’s likely that each of them will try to decline the responsibility for project, as they will not have enough time to take the initiative and coordinate the overall interaction.
• The programmer, just like any other person gets tired. If on the average he writes 500 lines of code, and he creates beautiful code, then under the pressure of deadlines he begins to write 750 lines of code. But it will not last forever, as he will start to write ugly code and sooner or later returns to his 500 lines of beautiful code. And right after this overdue task he’ll rollback to negative results with 250 lines of code.

In the end, the programmer will think: "What is my fault? Why must I put extra effort into work? Just because of incorrect terms estimation? ". Because of these thoughts people start to loose motivation too quickly.

How to solve the situation?

As usual, truth is somewhere near between manager and programmer. From managers’ side it is necessary to:

• Let your programmer to designate his own terms. If I see that programmer feels pressure from my side, then I’ll try to dispose this pressure, because I don’t need the programmer, who designates wrong terms when he sees me.
• Watch over terms validity. If programmer replies to my question: «It will be ready in 1 month», then it’s better to demonstrate plan for that, how he’s going to arrange his work into substeps, how quickly he’s going to finish each of them.
• Adjust understanding between programmers.

If this is done then:

• Programmer won’t feel himself depressed if he can’t finish his task on time. He turns to his manager with the following question: «I have no time to finish … what should we do? Can we assign the additional resources to this task or just carry over?».
• Programmer will be more sincere with manager, as he won’t feel sense of guilt. In programmers’ eyes deadlines are stop being as punitive tool.
• Look after honesty and fairness in group. There are always programmers who try to gain benefits in a roundabout way. Such programmers should be excluded from team, as they undermine morality.

From programmers’ side it is necessary to:

• Adjust understanding with manager too. Programmer doesn’t want to come to the manager and say "I have no time to ...", and to fear that manager finds him lazy.
• Evaluate logically the amount of work.

Moral and summary

There are no right or wrong in the situation. If the quality or speed of software development falls due deadline policy in company, then both are guilty.

Using schedules is necessary and convenient. But it seems to me that schedules should be soft, as employees should understand that sometimes it is better not to meet deadline, rather than write low-quality code or to exhaust themselves emotionally. We are not clairvoyants and the schedules sometimes can be inaccurate, so you need to understand that sometimes schedules can be adjusted if there are good reasons for this and better to discuss such reasons long before deadlines.