Why are Deadlines Important Even Though I Hate Them? [21/100]

I don’t like deadlines. You don’t like them either. Nobody does. I guess the very concept of a deadline is deeply unlikable. But almost everyone uses it. How come? 🤔

First off, there are two types of deadlines: natural and artificial ones. For example, an exhibition on October 25 is a natural deadline. A feature that should be ready on August 1 because we’ve done some estimating and decided this way is an artificial deadline. Natural deadlines are, for obvious reasons, also hard deadlines, while people tend to be less impressed by artificial ones.

In software development, deadlines are kinda loved. 💘 Managers turn literally everything they touch into deadlines. Every milestone becomes a deadline. Any time estimation becomes a deadline when a manager gets their hands on it. The end of each phase in the waterfall model becomes a deadline. Iterative development is just one endless avalanche of deadlines. Since there are a lot of deadlines over there, they’re probably essential. Apparently.

The deadline is an imposed limitation, and it has a couple of useful properties and some disgusting side effects that work for a big project, small project, just any project at all. Let’s poke it all with a stick a bit to understand what deadlines are made of.

Good: predictability of work

Basically, deadlines are used to foster predictability. It’s a kind of wishful thinking: at least something will be ready by the specified date. And damn it, but it works! I had a daily deadline for long reads, every day, by midnight. I daily publish something by this time. It’s not always good, but then I did it, published another blog post, well done.

Say your contract with a client contains penalties for each day of delay. Well, I’m positively sure you will deliver at least something to the client on day X. Or, say, you’ve got an exam in three days. Most likely, you’ll read something for it in these three days. Some way or the other, most people won’t read stuff for an exam that’s five months away. That’s called student syndrome.

Good: Minimizing costs of work done wrong

You can work on wrong things for a very long time. A product nobody really needs is a great example. Or a feature nobody needs. The longer we do something wrong, the more it costs. A deadline helps us to end this cycle and not go broke. For a product team, that’s also the only way to stay sane.

Well, it’s also possible we’re doing something right, but doing it the wrong way, half-assing every task all along. At a certain point, it always becomes clear that everything needs to be redone. This is where an old joke comes to mind: you shouldn’t postpone things to half-ass them, half-ass them immediately so that you’ll have enough time to rework. Procrastination is bad, so set deadline and don’t be lazy.

Good: Balancing quality and technical debt

Almost all good developers have serious quality bias in their work. They hate technical debt and the entire banking system with its interest rates, murky schemes, and creepy management. Good developers are quite persuaded that they will never get a chance to pay back their code debt because they feel driven into debt bondage with absolutely essential new features and demands to stay ahead of the market.

Therefore, a developer uses all the available time to implement features, trying to do everything as well as possible. Development work without a clear deadline requires some incredible professionalism and a sense of balance that only brilliant engineers have (and those are rare). So sensible use of deadlines in the product plan introduces clear quality constraints, forcing good developers to resort to technical debt.

Unfortunately, quite often, deadlines are set in such a way that technical debt overflows everything and obfuscates every important task there is.

Now, let’s talk about the cons.

Bad: Overtime

Working overtime is an obvious result of a tough unrealistic deadline. They say that in game development, everybody does it. I’d really like to have a look at the suicide rate by the industry for software developers.

Overtimes are frankly messed up. Seriously. It only gives you an exciting timeline of overwork, burnout, productivity loss, depression, sick leave, and long recovery. 🤕 Working extra hours might happen for a couple of days, but never weeks or months. Sometimes it’s necessary, yes, when you’re doing a really, really important thing. But keep in mind, anything longer than this will backfire!

Bad: Too many deadlines

People set deadlines everywhere, no matter if it makes sense. I dislike iterative development for this very reason. It imposes deadlines on everything. Of course, when you have a deadline every two weeks, you get used to it, the price of a mistake isn’t very high, overtime is not required, I guess, we can call it life…

With all that overflow of deadlines, it somehow becomes difficult to immerse yourself in an important and non-trivial problem for a month. The manager rushes you, demands to participate in stand-ups, to break everything down into smaller tasks, evaluate, prioritize and integrate stuff all day every day. The only thing you want is to pick open half of the system in a branch, twist complex structures in your mind, then reassemble everything into a much more beautiful form, having experienced a true engineering orgasm. But no, no orgasms for you, my friend, don’t you see we’ve got Scrum to do?

So what?

I don’t like deadlines. We need to use them, though. Sometimes. Selectively. Sensibly. But we can’t do without. It took me ten years to figure this out.