Dates are a common proxy construct used in conversations between engineers and non-engineers.

When will this feature/bug/task/ticket be done? Can you give an ETA?

I was told once - as if it would incentivize me to just speak dates - that "We won't put your head on a spike if the date you give us is off."

I didn't have that date. I would have given it out - even just to get out of this useless conversation. It would have cumulated hours of my and my team's time to find a reasonable date, for no good reason other than a Jira ticket being labelled as a bug.

The circus

So, a few people agreed to spend time to find out a reasonable Date for That Thing to be ready. The first ignored fact of the circus, usually, is that the accuracy of The Date is directly correlated to the time it takes to find it out, especially for bugs and technical debt. So, a few people must "invest" the right amount of time to have the most accurate date possible. This is a very fine line to walk on.

Optional at this point: The Date might not fit The Agenda (ironically) and is repurposed with abstract constructs such as buffers and margins that are getting out of people's noses and thumbs.

As the circus continues, when The Date is communicated, it is written somewhere without The Thing. Nobody's to blame here. It's far easier to write down a date than what's behind, such as risk, value, options, alternatives, workarounds, etc. It's a common term that fits an Excel cell's original size.

Then, The Date will be used, again without the full context, in all discussions as a proxy for complexity or lack of other common language. Or lack of skills in understanding how software is built and maintained. No one is to blame again; it's human. Dates are very concrete things that can be located in a calendar, to which we can wake up.

The Date becomes The Thing.

So, everyone forgets a little bit about the context. When The Date came, engineers didn't update the stakeholders. Why should they? They were asked for The Date, not a seat in the building process.

Stakeholders and engineers forgot all the context that came with The Date. The ifs and maybes and whys.

So everyone acts surprised because The Date itself has come with perfect predictability, but The Thing is still not done, or partly done, or even done for a long time. Whatever.

This is when need to "invest" time again speaking about The Thing, starting from The Date, investigating why, again, The Date and The Thing are not the same thing. We dig into notes and email threads, searching Excel sheets, arguing, finding out, asking ourselves how can it be that the circus is the same as the last one, and finally end up on a New Date with the same dumb hope that this time we have learned from our mistakes - and will monitor more closely The Date.

Knowing the circus, having my head on a spike in front of someone's office entrance might be a glorious way to serve as an early warning that dates have no more value than the context they come with.

The funny thing, is since I did not give out a date, the same person went over my head to escalate the fact I did not give out a fake date. So I did, to some extend, end up with my head on a spike for not giving out a date.

What matters more

Not being an engineer or the one writing the code doesn't prevent anyone from trying to understand the context, help with it, write it down, and translate it so everyone eventually gets what impact software engineering timelines...

• Who needs The Thing? Why?

• What was documented related to it? What was communicated? How can we communicate it so we don't speak about dates again?

• What are other things impacting The Thing? Yes, other unrelated priorities have the most impact on your thing. Work in Progress is evil.

• Where should we write this down so more than the 4 poor cc'ed people in this email thread know about this context? (assuming the company counts more than 5 people...)

• How can we get updated about the status asynchronously without having to craft a new but already wrong cc list and send an email with the question, "What is the status of that thing below?"

• What is the risk if we don't do The Thing? Is everyone ok with that risk?

• What are the options? The workarounds? Did we write them down? Does everyone know about them?

The same people are evaluating and doing tasks in Software Engineering. Every time they have to estimate a task, it takes away time from all the team's tasks. There needs to be a balance between estimating and doing.
Similar to the Observer effect in physics, adding dates and estimations to tasks has an impact on the tasks themselves - good or bad.

Dates should be handled with care and discussed only when they are part of the value of the task.