"When will this be done?"
When an engineer says, "I think about three days," a manager often writes down, "Due: Thursday."
This is the Translation Error that kills projects. We treat software estimates as firm promises or contracts. In reality, they are probabilities.
The AI Parallel: Prediction vs. Calculation
If you have been struggling to understand what "probabilistic logic" means when referring to Generative AI, software estimation is actually the perfect mental model.
When you ask an LLM a question, it isn't retrieving a verified fact from a database (deterministic). It is predicting the statistically most likely sequence of words based on patterns it has seen before (probabilistic). It is not rooted in logical outcomes based on reliable factors; it is based on the most likely outcomes based on similar situations.
Human estimation works the exact same way. When an engineer gives an estimate, they are running a mental simulation based on their past experiences. "Last time I built a login form, it took 3 days." They are predicting a future based on a fuzzy recollection of the past.
Just like an AI can "hallucinate" because it lacks full context, an engineer's estimate can be wildly wrong because they cannot predict the future state of the code, the API dependencies, or the interruptions that will occur on Tuesday.
The Cone of Uncertainty
Software engineering is discovery. You are building something new, often on top of shifting dependencies. In the beginning of any project, the "Cone of Uncertainty" is wide. Asking for a precise deadline at this stage is a mathematical impossibility.
It ignores the "Sunny Day" Fallacy: Engineers naturally estimate based on uninterrupted coding time. They rarely account for the reality of production outages, planning meetings, context switching, or the API documentation being wrong.
The Cost of Determinism
When leadership demands deterministic dates for probabilistic work, they force the engineering team into one of two destructive behaviors:
-
Massive Padding: To avoid being "late," engineers start tripling their estimates. "3 days" becomes "2 weeks." The organization slows to a crawl to protect itself from management's wrath.
-
The Optimism Trap (Lying): To please leadership, the team commits to a date they know is impossible just to get the stakeholder off their back. When reality hits, they cut corners, skip testing, and burn out.
Shifting to Confidence Intervals
The solution is to change the language. Stop dealing in dates; start dealing in ranges and confidence intervals.
Instead of asking, "When will this be done?", try:
-
"What is a high-confidence range for this feature?" (e.g., 3 to 5 days).
-
"We are targeting Friday. What is your confidence level in hitting that?" (e.g., "I'm 60% confident for Friday, but 95% confident for next Tuesday.")
This approach shifts the dynamic from a negotiation of time to a management of risk. It allows the business to make informed decisions based on reality, rather than comforting illusions.
A leader who demands exact dates for complex innovation isn't asking for accuracy; they are asking to be lied to.