The Danger of the "Two-Week" Lie #
- Developers often default to "two weeks" when pressured for a timeline on projects they don't yet understand.
- Providing a deadline without understanding the scope is professional "suicide" that leads to burnout and project failure.
- Stakeholders and PMs often ask for dates out of anxiety; they want a number to feel like they have a plan, even if that number is baseless.
- Agreeing to a best-case scenario timeline is effectively signing a contract that is impossible to keep.
The Rule of Ranges and Precision #
- Never provide a single date; always provide a range (e.g., 3 to 6 weeks).
- Acknowledge that early estimates are naturally volatile and will only narrow as more information is gathered.
- Correlate the precision of the timeline to the precision of the requirements; vague requests deserve vague timelines.
- If pushed for an immediate answer, request a "research buffer" (e.g., two days) to investigate the codebase or requirements.
Strategic Scripts for Refusal #
- The Risk Transfer: Explain that a single date has a high probability of being wrong and ask if the stakeholder is willing to accept that risk.
- The Discovery Proposal: Commit to providing a believable range by a specific time (e.g., Friday) after a short period of "digging in."
- The "No" with a Pathway: Explain that a rushed timeline results in "shipping junk" and offer trade-offs, such as delaying other work or adding more resources.
The True Cost of Poor Estimation #
- Bad estimates account for roughly half of all projects going over budget.
- "High pressure code" is statistically shown to have 15 times more bugs than code written under reasonable timelines.
- Rushed work is "borrowing at a massive interest rate," as shortcuts taken now will require significant future effort to fix.
- Inaccurate dates destroy professional trust and damage the business's ability to make informed decisions.
Summary #
Providing "fake" dates to satisfy anxious stakeholders leads to technical debt, career burnout, and project implosion. To maintain professional integrity, developers should replace single-date deadlines with estimated ranges, insist on research time for discovery, and reframe the conversation around trade-offs and precision. Ultimately, a developer's job is not to provide comfort through lies, but to provide the uncomfortable truth so the business can plan effectively.
last updated: