Deadline Driven Development
— Chapter 5 —
Deadlines seem to be an inevitable way of life for software engineers. When you’re working on a project, there are always other people invested in that project along with you, such as managers, PMs, tech leads, and the customers. These people want to know when you’re going to be done with your project. That is reasonable, to a degree.
I am not making the claim here that there should be no deadlines whatsoever. Deadlines can be necessary to handle the expectations of your stakeholders: your clients, managers, tech leads, etc. Deadlines can also be a good motivator for the team: When they see that the end is in sight, and how close they are to finishing the project, that can give the team a great sense of accomplishment and motivation.
But all this assumes that the deadlines are reasonable, and are set by the team of engineers themselves, not by the managers or the sales folks or anyone else. Unfortunately, this is not always the case.
The real issues show up when the managers, PMs, marketing folk, etc. don’t like your estimations and start pushing for an earlier deadline. Or when they expect you to give them a certain exact date, and expect you to deliver on that date without any leeway. Or when they expect you to work 50+ hours a week so you can deliver on their arbitrarily arranged deadlines. Or when they start micromanaging you and do the equivalent of asking you “are you done yet?” every day.
This is a special kind of hell. This is the hellish world of Deadline Driven Development.