My Thoughts on Estimation and Hitting Delivery Dates in Software

I completely empathise with the frustration many non-technical leaders feel when software teams can't give a clear delivery date.

In most other industries, you can see progress. A building goes up brick by brick; you can touch it, measure it, and know when it's nearly done. Software doesn't work like that. Most of the progress is invisible until very late. The foundations (architecture, data models, testing, performance, security) are hidden beneath the surface.

That's part of what Fred Brooks (Author: The Mythical Man Month) called the "intangibility problem" and it leads to what I think of as the software construction fallacy: the assumption that building software is like building a house. It's not. It's far closer to research and design than to construction.

And to be fair, even the construction world struggles. Studies show only about 25–30% of large construction projects finish on time and on budget [1]. In IT and software, it's similar around 30% succeed fully [2], the rest overrun or change scope. We've all seen Grand Designs: projects running late, costs ballooning, compromises creeping in… and occasionally, someone key to the delivery gets pregnant halfway through the build!

Predictable delivery dates are possible but only for small, repeatable efforts. The irony is that those efforts rarely move the needle. If the work is fully known and easy to estimate, it's probably already been done before, or could be done by anyone.

The real value — the kind that creates new markets, or transforms how customers work — comes from making something from nothing. That's innovation. And by definition, innovation lives in the space of unknown unknowns: learning what works, adapting, discovering. You can't schedule discovery with precision.

So while I empathise deeply with the desire for predictability (and we should always improve how we communicate progress and reduce uncertainty), I also think we need to celebrate the other side of the equation: that we're in the business of R&D, invention, and value creation not just project management.

Over time I've found something interesting: once a team is clearly delivering value, solving real problems, and focusing only on the most important thing next, people stop fixating on dates. Trust grows. Outcomes start to speak louder than estimates.

Because at that point, everyone can see the momentum even if they can't see the brickwork.

Curious to hear from others: when have you seen a team shift the conversation from "when will it be done?" to "what are we learning and delivering next?"