Stop With Software Estimates

Software estimates consistently fail because they try to predict novel work—work that can’t be fully specified until teams start building it. As projects grow beyond small, routine efforts, uncertainty compounds: the industry keeps treating estimation as a solvable problem, even though “what work really is” only becomes clear after prototypes, partial builds, and course corrections. The core takeaway is blunt: relying on time-based forecasting for software delivery is often delusional, because the real requirements and the real solution emerge during implementation.

A key distinction drives the argument: when software becomes predictable enough to estimate, it often becomes something people can buy—like off-the-shelf tools for content management or e-commerce—rather than something teams must invent from scratch. That means most meaningful software work is inherently novel. Novel work can’t be fully planned upfront because nobody knows exactly what it should look like until building starts. That leads to a second failure mode: teams also assume they can specify what customers want before they understand the problem well enough. The result is “half of a wrong solution,” followed by changing direction once the team finally learns what the real problem was.

Instead of “try harder” estimation, the proposed alternative is to change tactics: stop treating delivery as a promise of time and start treating it as a budgeting problem. In the Shape Up framing discussed in the conversation, teams set a budget (money) and then work within it, pruning scope as learning happens. The logic is that budget is not the same as a calendar estimate: a budget creates a constraint that forces trade-offs, whereas a time estimate invites a false sense of certainty. If a project can’t be completed within the budgeted effort, teams adjust scope to ship something valuable rather than stretching toward an arbitrary deadline.

The discussion also pushes back on a simplistic “budget equals time” equivalence. Even if money maps to capacity, the practical difference is behavioral: budgets encourage scope reduction and focus on the core product, while estimates tend to lock teams into delivering everything originally imagined. Great software, the conversation suggests, is built through concessions made while moving forward—trade-offs that reflect what’s actually working and what’s not.

Participants then debate where this approach fits in different organizations. Some companies can run with small, focused teams that operate with high independence and minimal process overhead; others get trapped in a culture of standups, constant measurement, and scope creep driven by shifting stakeholder demands. The group also touches on survivorship bias: success stories often come from unusually effective teams and products, making it unclear how transferable the method is to larger, more bureaucratic environments. Still, the shared conclusion is that abandoning estimates can help teams ship better and sooner by replacing prediction with disciplined constraints and iterative learning.

By the end, the conversation circles back to practical next steps: read the Shape Up methodology, understand how budgets and scope pruning are operationalized, and consider whether the approach can be adapted beyond the small-team context where it’s proven.