What does a date actually mean?

And why do we continually shoot ourselves in the foot with them?

The bane of every software engineer's life is dates. And I'm not talking about date types in programming languages, nor am I talking about programming with timezones. I'm talking about the biggest thing that we continually, despite our best intentions, shoot ourselves in the foot with: just when exactly is that project going to be done?

Let's face it: estimates are incredibly hard to make. Sometimes they are closer to fiction than they are to fact.

Now, companies want estimates from us for entirely reasonable reasons: they want to understand how they are investing their expensive engineering resources over time, ensuring that they're making the best trade-offs between what to do and what not to do. It makes sense.

However, despite all of us being pretty good at writing software, which is a complex and highly skilled task, we're absolutely awful at estimating how long it will take. Shockingly so.

And I'm not a unique case: I've been on projects that seemed like they would take a few weeks, but ended up taking a whole year. I've also been on projects that seemed like they would take a year, but ended up taking a few weeks. It happens. Every new software project is a journey into the unknown. However, it's typically the former that happens more often than the latter.

But this isn't an article about how bad we are at estimating (note: we are), nor does it offer any solutions for you to getting better at estimating. In fact, I want to focus on why dates are pretty dangerous things to be throwing around in the first place, and what an alternative might look like that could save you a lot of pain.

A new project

Let's imagine that your team starting on a new project: you're building a cool new feature on the product that you own. Everything is going well. You've spent some time together as a group whiteboarding what needs to be done, you have a high level diagram of the component pieces and how they interact, and you've broken the problem down into enough granularity to be able to start distributing the work amongst the team.

So, you're all feeling good so far.

The last step is to get the work into your project management tool, so you create the tasks, assign them to people, and you wrap them in an epic project container that represents the new feature.

But hang on a second; you can't click "Create" until you've put a date on it, so you quickly ask the team:

"Hey, when do you think we can get this done by? Gotta put a date on it."

"Uhh, I don't know, maybe a month?"

"Yeah, okay, let's say the end of October."

You open up the date picker, select the 31st of October, and click "Create".

Done.

In the project management tool your team is now shipping this feature on the 31st of October. But that doesn't matter, right? Or does it?

The ambiguity of dates

Here's the problem: the 31st of October can mean different things:

• To your team, it means that you'll probably be done in around a month, but you're not sure. You're just guessing and getting that date field filled in so you can move on.

• However, to people outside of your team, they may see that specific date is a commitment. This is the date that they're going to be able to use the new feature.

That's problematic. Just by setting a date, you may have started a number of wheels in motion that you didn't intend to:

• Marketing might start planning a campaign around the new feature, expecting it to be ready by the 31st of October.

• Sales might start talking to potential customers about the new feature being available then as part of a sales pitch.

• Other features that depend on your feature might start sequencing their own work around that date you set.

• And here's the worst part: you may have just accidentally set yourself up to appear incompetent if you need to move the date back.

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 behaviour. 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.

Forecasting

When you go to the cinema and watch the trailers before the movie, you'll notice that they often don't give specific dates for when the movie is coming out. Instead, they might say "Coming Soon", "2026" or "In Theaters This Summer".

Why is that?

It could be that the movie hasn't finished production yet, and they're not sure when it will be done. Perhaps they are still securing the distribution deals, or maybe they are even purposely waiting for a good time to release it so that it doesn't clash for box office dollars with another movie.

But, whatever the reason is, they don't want to commit to a date that they can't be sure of. They don't want to set expectations that they can't meet. What they're doing here is forecasting. And strangely, you don't feel like you're being lied to when you recieve a forecast. You understand that it's a guess because of the lack of granularity.

And it isn't just movies that do this. Games do it too. At the time of writing, Grand Theft Auto 6 is due out in Autumn 2025. Video games have a long history of low granularity forecasting that tapers down to a specific date as the release approaches. The Wikipedia page for video games in development are predominantly tracking an "unknown" release date.

This is because large complex projects like software follow an uncertainty curve that looks like this:

• At the start of the project, you have the most uncertainty. You don't know what you don't know, and you're just guessing at how long it will take.

• As you progress, you ideally focus on the work that reduces the most uncertainty first. This is why we do spikes, proofs of concept, and prototypes.

• As more work is done and unknowns are turned into knowns, you begin to taper off the uncertainty and hone in on a more accurate estimate of when you'll be done.

• These estimates progress from high granularity (e.g. "Q4 2024") to low granularity (e.g. "October 31st, 2024") as you complete the work and get closer to the end.

Even though none of the above is likely new to you, setting specific dates up front is the footgun that we keep shooting ourselves with as an industry again and again. We arbitrarily assign dates that we can't be sure of, and then we deal with the fallout when we can't meet them.

Granularity and one-way doors

From a psychological perspective, this is because the lowest level of granularity is often a one-way door.

Once you've set a specific date, it's hard to go back to a higher level of granularity: after all, you knew the date, so why can't you meet it? What then happens when teams miss a specific date is that they append some more time to it, and then get a new date.

However, if it's too far in the future from the original date, then stakeholders start to lose faith in the team's ability to deliver. If it's too close to the original date, then the team is seen as incompetent or not working hard to get it over the line.

Both of these are lose-lose situations. All because of a date.

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.

If you imagine that you were working for an image sharing social media platform, then perhaps a forecasting-based roadmap might look like this:

You see, that looks a lot more reasonable, doesn't it?

It's clearly a forecast and not a specific commitment. The further out you go, the less certain you are. And that's okay: stakeholders understand, you understand, and you're not setting yourself up for being hit over the head when you have to move a date back because you've successfully uncovered some unknowns.

You owe yourself the ability to experiment with forecasting. Give it a go on your next project. Follow the uncertainty curve.

It might just save you a lot of pain.