The word deadline reminds me of uncivilised times when guards were shooting prisoners who were trespassing a line, sometimes even invisible, representing a limit beyond which there was freedom.
Prisoners died for going beyond the deadline. Software projects die for managing to stay behind it.
What kills projects that respect deadlines
How can a project fail if it delivers within the deadline? Isn't it what they are supposed to do?
When managers set deadlines, developers feel that they must meet them at all costs.
Deadlines may be unrealistic and force developers to work long hours, or may be reasonable. In the latter case they may still cause problems.
Deadlines don't make developers more productive
Contrary to popular belief, developers who are required to run against a deadline are not more productive.
Researchers have found that developers who have no deadline to meet may be 50% more productive.
Deadlines cannot be correctly estimated
They are easily underestimated, particularly when people who define them have little knowledge of how the software development process works.
Even if a deadline originates from accurate information, it may still have large statistic variations because developers may encounter technical problems, the task's definition evolves or the application has to undergo unexpected redesign.
It's very common for the development team to have to change the scope of an application sometimes even radically. This makes deadlines even more dangerous. The solution is not to enforce the deadline at all costs, results would suffer or just be zero.
Developers who run cannot think
It's already hard to think in most working environments where interruptions are galore. Some developers take refuge on a hammock to be able to mull over complex problems.
Deadlines will chase them even there and disrupt their ability to figure out a solution.
Deadlines tend to become a developer's major concern. She will see thinking as a waste of time. She will rush to write the code that first comes to her mind as a possible solution.
Quality gets put aside
When rushing to stay within time limits, developers sacrifice quality. Their code will barely work, bugs will abound, documentation will be absent and structure will be precarious.
This will make developers less motivated. Who can be motivated to build something mediocre? Loss in motivation will make developers less productive.
What about cooperation?
When developers have to run, they run alone. Managers measure their individual performance forgetting that it's the team that produces results.
Developers are reluctant to help others because this will slow them down or so they believe.
Actually cooperation motivates and improves productivity, at least the team's.
Time limits shut developers up
Time limits are a motion of no confidence. Managers set them because they don't trust developers with getting things done without deadlines.
Developers who are not trusted think that they have no right to ask questions, they just keep their heads down and produce.
Asking questions is the most important activity developers do to achieve good results or sometimes any result at all.
How did we get here?
How is it that we are still using deadlines to organize work when they are actually harmful?
If a company is making shoes, workers' tasks are simple, well-defined, organized in procedures and ask for no problem solving skills or only for elementary ones.
Everything is predictable and setbacks that cause delays are under control most of the times.
Managers don't need to understand how things work. They have just to single out the worker responsible for a delay or a mistake and reprimand or fire them.
Are you safe from deadlines?)