Sean Goedecke argues that software estimates often serve negotiations over funding, priorities and scope. Managers frequently have a desired deadline before engineers examine the code. He starts by finding that constraint, then asks which approaches could fit it.
- Get the context first. Establish whether the request is exploratory or tied to a deadline leadership considers essential.
- Investigate the unknowns. Unfamiliar systems and hidden dependencies matter more than adding up the steps already understood. Planning can move that investigation earlier, but cannot make it free.
- Offer alternative designs. His example contrasts six months building a robust PDF-chat pipeline with one day extracting text into a model’s context or providing a search tool. These are different products under the same feature label.
- Return a risk assessment. Explain what must go right, what can be bypassed, and whether help from a team familiar with the system would reduce uncertainty.
- Say when no approach fits. If the feasible set is empty, leadership must change the requirements. Goedecke argues that a record of pragmatic compromises makes that warning more credible.
He allows that small, familiar tasks can be estimated accurately. His stronger claim about estimation being impossible concerns projects dominated by discovery in existing large systems. In later updates, he also stresses that estimates cannot be transferred unchanged between teams with different capabilities.
Caveat: this is an experience-based argument about organizational behavior, not a measured comparison of estimation methods. Its practical recommendation is to make scope and uncertainty explicit; a desired deadline still does not establish feasibility.