When did estimates turn into deadlines?
Software engineers describe how rough time estimates for projects routinely harden into de facto deadlines, despite the inherent uncertainty of complex, creative work. Many recount padding their estimates or refusing to give numbers at all as a defense against anchoring bias, scope creep, and blame for overruns, while managers still need timelines to coordinate sales, marketing, and budgets. Suggested remedies include expressing estimates as ranges or probability distributions, explicitly accounting for risk and unknowns, and building organizational cultures that treat estimates as collaborative planning tools rather than rigid commitments.
Why Estimates Become Deadlines
- Many commenters say the first number uttered “sticks” due to anchoring bias; managers often treat it as a commitment, not a forecast.
- Estimates tend to get propagated up the org chart or into sales promises and then become politically immovable.
- Some report estimates being aggressively “negotiated down” and then enforced as hard deadlines.
Padding, Heuristics, and Coping Strategies
- Widespread use of rules of thumb:
- Multiply by 2 or 3 (or π), or “double and bump the unit” (hours→days, days→weeks).
- Give ranges (e.g., 6 weeks ± 2) or confidence levels (e.g., 90% likely).
- Many explicitly overestimate to survive blame culture, handle scope creep, and create slack for untracked but necessary work (documentation, mentoring, firefighting).
- Others warn that “super-inflated” estimates can look incompetent, especially to technically savvy managers.
Management, Culture, and Incentives
- Bad patterns described:
- Treating every estimate as a deadline; ignoring changing specs; punishing overruns, ignoring causes.
- High “volatility” in sprints (constant ticket swaps) destroying predictability.
- Some argue good managers use estimates as planning tools, accept uncertainty, and shield teams; bad ones use them as sticks.
- Several highlight that managers themselves face pressure from their own bosses, customers, and investors who need dates to coordinate sales, marketing, and contracts.
Nature of Software Estimation
- Debate over whether poor estimates are a “skill/experience issue” or fundamentally constrained by unknowns and lack of upfront paid investigation.
- Comparisons to construction, healthcare, and law: other fields also estimate and pad for risk, but software’s novelty, legacy complexity, and cross-team dependencies make it harder.
- Spiral/iterative development and “no estimates” approaches are suggested to focus on delivering small increments and learning, rather than long-range precision.
Proposed Better Practices
- Break work down; estimate only well-understood chunks.
- Explicitly separate scope (“engine” vs “complete feature”).
- Communicate ranges, risks, and confidence, and update regularly.
- Track actual vs estimated to calibrate multipliers per team/person.
- Fix culture: blameless postmortems, tolerance for honest misses, and realistic alignment of value, scope, and time.