James Stanier has a good argument for why deadline-driven development is so… difficult:

Given that non-technical people don’t understand why software is hard, dates become the stick that they beat you with when you don’t deliver on time. Don’t ask me why, it’s just human behavior. I’m sure you’ve done it when roadworks have taken longer than were specified on the sign, or if a delivery of a package was late. Dates mean something to people, so handle them with care. In fact, perhaps we could do something entirely different instead.

What’s the “something different”?

So, instead, you should take a forecasting approach that follows the uncertainty curve that we outlined above. You start wide, and you taper in. At the beginning of a given project, you might even just have the year that you’re aiming to ship. Then, as you progress, you can start to narrow it down to a quarter, then a month, and finally a specific date.

This is why I will always advocate for time horizon roadmaps.