Software engineer Sean Goedecke has published a critique of conventional project estimation, arguing that estimates are often less useful as forecasts than as organizational tools for choosing scope, funding and priorities.
Goedecke’s central claim is that most meaningful software projects cannot be predicted accurately in advance because much of the work is discovery. Engineers must inspect unfamiliar systems, find prior approaches and determine how a proposed change will affect existing code. Those unknowns consume much of a project’s effort, yet only the already-understood tasks can be estimated with confidence.
He distinguishes that work from small, repeatable changes. If a deployment process is familiar and the requested edit is narrow, an engineer can reasonably add the known time needed for coding, continuous integration and release. Large-system development is different: planning cannot eliminate uncertainty without effectively doing the investigation and implementation first.
The essay also questions familiar attempts to make estimates feel more rigorous. Teams may label work with T-shirt sizes instead of durations, only for management to convert those labels into hours or days. Engineers may apply buffers or rules of thumb to their first guesses. In Goedecke’s view, these practices do not resolve the underlying lack of knowledge.
Yet he does not conclude that companies should simply abandon estimates. Instead, he describes them as inputs to business decisions. Managers and executives use schedules to decide which projects deserve funding, which should be cancelled and which ambitions must be reduced. Organizational pressure can also shape the number: a favored proposal may be pushed toward a shorter estimate, while work intended to preserve capacity may receive a larger buffer.
That interpretation reverses the usual sequence. Rather than fully define a project and then discover its duration, a team can begin with an available time budget and select an implementation that fits. Goedecke uses a hypothetical feature allowing users to talk with a PDF. With months available, a team might build uploads, semantic retrieval and image extraction. With one day, it might place extracted text directly into a language model’s context or offer basic text search.
The practical lesson is not that deadlines reveal how long a fixed solution will take. They determine which solution is feasible. That framing makes uncertainty explicit and turns estimation into scope negotiation. It also preserves a warning: a schedule selected for organizational reasons should not be mistaken for a precise measurement of engineering complexity.
Goedecke’s essay is a practitioner’s argument rather than empirical research. Its value is the model it offers teams: discuss the constraint, expose the unknowns and adapt the work, instead of presenting an uncertain forecast as objective fact.
