Guess Less, Learn More: Navigating Software Without the Certainty Illusion

“How long will it take?”

It’s the question every engineer dreads. Not because we don’t want to deliver — but because, more often than not, we genuinely don’t know. And pretending we do only sets everyone up for frustration.

The truth is, most software development isn’t predictable. It’s not manufacturing. It’s not digging trenches or laying bricks. It’s discovery. And the more we act like we can forecast every twist and turn, the more time we waste playing the estimation game instead of building, learning, and adapting.

Software is Learning, Not Assembly

When we estimate tasks, we often assume that we know all the requirements, edge cases, and dependencies up front. But how often is that true?

Most of the time, we’re:

Investigating unfamiliar codebases

Experimenting with tools or APIs

Making decisions based on user feedback

Discovering bugs, edge cases, or upstream issues mid-flight

This is not failure — this is software development. Treating it like an assembly line ignores the reality that much of our work is about reducing uncertainty and making better decisions as we go.

As Kent Beck puts it: “I’m not a great programmer; I’m just a good programmer with great habits.” One of those habits is recognizing that the real work is in the figuring out, not the typing.

The Cost of Estimation Theater

Let’s talk about the rituals: story points, planning poker, t-shirt sizing, and timeline forecasting sessions that stretch for hours. Most of these are well-intentioned, but in many teams, they devolve into estimation theater — the illusion of precision, built on top of guesswork.

Here’s what we trade away for the sake of feeling certain:

Time: Hours spent estimating could be spent prototyping, testing, or validating.

Focus: Developers start optimizing for hitting deadlines, not solving problems.

Trust: When estimates inevitably miss the mark, the credibility of the team takes a hit.

Creativity: Rigid timelines discourage experimentation and reward the safest path.

We pad numbers to protect ourselves. We round up to account for meetings, blockers, and “unknown unknowns.” But the more we pad, the more we distort — and soon we’re arguing over fiction instead of focusing on learning and outcomes.

What to Do Instead: Measure Progress by Learning

Rather than trying to predict everything up front, we should invest in reducing uncertainty early. That means:

Timeboxing exploration: Allocate a few hours to answer, “Can this be done?” before asking “How long will it take?”

Shipping smaller slices: Get feedback faster and validate assumptions with real users.

Tracking decisions, not guesses: Document what you’ve learned and what changed — that’s more valuable than hitting a made-up deadline.

Recognizing learning as progress: If a day spent debugging a thorny issue avoids three weeks of the wrong solution, that’s a win.

The goal is not to eliminate planning — it’s to replace guesswork with feedback.

Direction Over Prediction

Instead of asking developers for detailed timelines, ask for direction:

What’s the problem we’re trying to solve?

What’s the riskiest part?

What’s the fastest way to learn whether we’re on the right track?

When teams align around a direction — a clear problem and a shared understanding of constraints — they move faster, make better choices, and course-correct early. That’s more valuable than any spreadsheet of sprint points.

Let Engineers Navigate

Good engineers are not just builders — they’re navigators. They explore unfamiliar systems, chart paths through ambiguity, and adapt when the map turns out to be wrong.

If you want reliable outcomes, don’t ask for perfect estimates. Create space for exploration. Encourage feedback loops. Invest in fast learning.

Because in the end, building software is not about being right on the first try — it’s about learning fast enough to get it right over time.