One of my favorite lines from Douglas Adams’s Hitchhiker's Guide to the Galaxy is, "I love deadlines. I love the whooshing noise they make as they go by." Deadlines are a fact of life, like taxes (which also have deadlines). It all probably started millions of years ago with the first humans needing to get things done before the sun went down, the need to get prepared for the winter, and get done with the harvest on time. Fast forward a couple million years and you can probably name 5 deadlines you have tomorrow. For me, due tomorrow is finishing this blog, two proposals, going live for a new website, a weekly update, editing a statement of work, and paying some bills that are due at the beginning of the month. So deadlines have always been with us and will continue to be until we get sucked up into a spaceship with a towel right before the earth gets destroyed to make way for a galactic highway, which probably won’t happen anytime soon, so let’s talk about them, specifically software project deadlines.
Depending on the type of company you work at, software project deadlines probably mean different things. I’ve worked at places where deadlines were just treated as an unhappy reminder how far we were behind but not really paid much attention until it came time to redo the roadmap, while in other places I’ve worked a missed deadline meant no pay, a fine for being late, or no more employment. In my experience most companies land somewhere along those two extremes. Neither extreme ships better software, they just made people miserable in different ways.
The same five things keep killing every project
According to the stats on the internet, only about 47% to 64% of software projects are completed and shipped on time. So why is making a software deadline basically a coin flip? You'd think with all the tools, technology, frameworks, practices, and now AI thrown into the mix, the odds would be a lot better than that, right?
Turns out it's not really a technology problem. We've all seen the usual suspects show up on the post-mortem slide: vague requirements, scope creep, poor estimates, unrealistic schedules, external dependencies, and resourcing. Everyone nods along in the retro, writes them down, and then somehow the next project has the exact same list. That's the tell. If the same five things keep killing deadlines project after project, company after company, it's not bad luck and it's not a bad sprint. It's systemic.
A missed deadline is almost never a scheduling problem
Here's the thing nobody wants to say out loud, a missed deadline is almost never actually a scheduling problem. It's a symptom. The date on the calendar isn't what failed, the date is just where all the stuff that was never really settled finally comes due. Vague requirements that got waved through, staffing that didn’t materialize, and estimates that folks either didn’t research properly or outright knew were inaccurate were agreed. Scope that grew in a hundred small "sure, we can add that" moments that never got added to the schedule (death by a thousand cuts). By the time you're staring down a deadline you're going to miss, the deadline itself is just the messenger. Somebody shoot the estimates and the requirements doc instead.
I've been the guy who said yes to a date I didn't believe in. Once a senior VP wanted to do a complete architectural lift and shift (unrealistic requirements) and pushed to hit a date that, in my gut, I knew was unrealistic. The second, "Yeah, we can make that work." came out of my mouth I knew things were not going to go well. I wasn't lying exactly, I was doing that thing where you convince yourself that if everything goes right, if nobody gets sick, if the third-party API doesn't change, if the teams we are dependent on make their schedule, if scope doesn't move an inch, it's technically possible with the right abstractions, shortcuts, and some luck… Everything did not go right. Nothing ever does. The project never shipped, at least in the form it was originally specified. It cost time, money, livelihoods, exhausted & demoralized teams, and in the postmortem "poor estimation" and “incomplete requirements” went on the list like it always does. What actually happened is I didn't say no to unrealistic requirements. That's not an estimation problem. It was a confidence problem. It took that debacle to convince me never to agree to unrealistic requirements delivered in an unreasonable timeframe. Even if it costs me my job.
A few things I've learned to actually watch for, the hard way
Treat the deadline like a leading indicator, not a wall. If you're paying attention, you can usually see a missed deadline coming months out, not days out. The trick is being willing to say something when you see it, not waiting for the calendar to do the talking for you.
Buffers aren't padding, they're honesty. Every time I've seen a schedule get "optimized" by cutting the buffer, I've watched that buffer get spent anyway, just later and with a lot more stress attached to it.
Say the number you don't believe out loud. If a date feels wrong the moment you commit to it, that feeling is data. It's usually right.
Watch for the "we'll fix it after ship" list. That list is where every unresolved decision goes to quietly become someone else's emergency, later or a show stopper at launch.
I still love the whooshing noise deadlines make as they go by. I just try to make sure it's not one of mine, or if it is, that at least I saw it coming and said something before it whooshed. Some deadlines you genuinely can't dodge, like taxes, or the electric bill that's due on the first no matter what mood the universe is in. But most software deadlines are more negotiable than they pretend to be. Knowing the difference between the two is key. The rest is just making sure you're not the one still typing when the sun comes up.
