Stop Filling the Jar: Why Arbitrary Deadlines Kill Good Software

19 December 2025

Picture this: Work drinks on a Thursday evening, a couple of pints in, when the account manager leans over. "How long to build this feature my client asked for, they need it in a month?". Your super keen developer, relaxed and helpful, shrugs: "That's not too bad, we can make that I reckon!"

Congratulations. That just became a delivery date.

A large customer, who you have a good relationship with, wants some feature improvement for an upcoming project. The casual pub chat transforms into a hard deadline. The team rushes. Corners get cut. Ship a bespoke build because there's no time for feature flags, just a custom deploy, right on schedule. The client replies: "Oh great! By the way, our project deadline got pushed a month."

All you can do is laugh.

The team spends the next month cleaning up technical debt they created in the rush, ships the proper version for the actual deadline, and everyone quietly pretends the first attempt never happened.

This isn't a story about one bad estimate. It's a story about how broken the entire system is.

The Coordination Trap

Look, deadlines aren't inherently evil. A conference demo needs to happen when the conference happens. Regulatory compliance doesn't negotiate. But most deadlines in software? They're complete fiction.

Here's what actually happens: A CEO who doesn't understand the problem asks "when will this be done?" Sales needs a date for the deck. A client sets a migration deadline (almost certainly from their junior employee who was too afraid to push back). Everyone's making up dates to feel like they're coordinating, and those made-up dates become gospel truth.

The real problem isn't the deadline. It's what you sacrifice to meet it. Teams don't skip testing or hack things together because they're lazy. They do it because someone turned a pub guess into a contractual promise, and now there's no time to understand what you're actually building.

In our story, the team never asked the fundamental question: What problem are we solving? They built something by the deadline. It just wasn't the right thing. When the pressure's on, you optimise for shipping, not for understanding. That's how you end up with garbage.

One Rock, Beautifully Placed

You know the rocks, pebbles, and sand analogy. Big things first, then medium, then small. Maximise what fits in the jar. It's supposed to teach prioritisation.

But that's exactly the wrong lesson for software.

Software isn't about maximising what fits in the jar. It's about having one rock, beautifully placed, that's better than every other rock in every other jar.

When you're cramming as much as possible into arbitrary timeframes, you end up with a jar full of mediocre pebbles. When you focus on one thing, understand it properly, and build it right, you ship something that actually matters.

This doesn't mean shipping slowly. Ship the rock early, as soon as it provides real value. But "early" isn't determined by a date someone invented in a sales call. It's determined by whether the work is good enough to delight users and hit the outcome you're aiming for.

The feedback from one excellent thing is clear and actionable. The feedback from a jar stuffed with half-finished features is just noise. Even if you could parse it, you'd still need to decide what to polish. And by then you're probably pivoting away from a pile of technical debt anyway.

Build for Outcomes, Not Timelines

The alternative isn't "never commit to anything." It's committing to outcomes instead of dates.

Your roadmap shouldn't say "Q1: Feature A, Q2: Feature B." It should say "We will solve this problem" or "We will move this metric" or "We will make this 10x faster." You aim for the target, iterate, measure progress, and decide quickly whether to keep going or kill it.

This takes however long it takes. The goalposts might move as you learn more. That's fine. That's called not being stupid.

When you sell software, sell what it does now. Not what it might do later. Buy technology for what it does today, not on the promises of future updates — see Tesla self-driving. The transaction should be about present value, not futures trading.

Does this mean clients never know when things will be ready? No. It means they get incremental value continuously instead of a big bang on an arbitrary date that everyone secretly knew was made up from the beginning.

The Uncomfortable Truth

Arbitrary deadlines aren't coordination. They're risk transfer.

Executives transfer execution risk to engineers by demanding dates. Engineers transfer scope risk back by padding estimates or cutting corners. Everyone lies to each other in spreadsheets. And somehow we've all agreed this is just how software works.

What if we stopped?

Focus on the rock. Understand the actual problem. Ship when it's genuinely good enough to provide value. Measure outcomes, not velocity. Fail fast if you need to, but fail because the idea was wrong, not because someone's guess in a pub became a legally binding commitment.

The pub conversation should have ended differently.

"How long to build this feature my client asked for?"

"I don't know yet. Let's talk to them about what problem they're trying to solve. Then we'll know if we're even building the right thing."

No dates. No promises. Just one beautifully placed rock.