Software Is Inherently Uncertain
Metrics tell you what you know — never what you don't. Software is uncertain by nature, so testing can only reduce that uncertainty enough to make a call.
Every software team wants the same thing before a release: confidence.
So they measure what they can. Test pass rates. Code coverage. Open defects. Automated tests. Requirement completion. Performance numbers. The assumption is rarely said out loud, but it shapes almost every engineering organization: if we collect enough data, we’ll know whether the software is ready.
It’s an understandable belief. Metrics reveal progress, expose regressions, and help teams talk about risk. Without them, releasing software would feel like guesswork. But there’s a subtle mistake hidden inside that assumption.
The limits of measurement
Metrics tell us what we know. They cannot tell us what we don’t.
No dashboard can measure the feature interaction nobody anticipated. No report can quantify the production environment that behaves differently from staging. No coverage percentage can promise that the next customer won’t find an entirely new failure mode.
This isn’t because the team did a poor job. It’s because software is inherently uncertain — and no amount of measurement closes a gap that is, by definition, made of the things you haven’t seen yet.
Every release is ultimately a decision made with incomplete information.
Two teams, one release
Picture two teams reviewing the exact same release. Identical dashboards — same pass rate, same open defects, same coverage. One team ships. The other waits.
Which one got it wrong? Probably neither.
Say the first team is shipping an internal admin tool — if it breaks, they roll it back in minutes. The second is deploying payment infrastructure in the middle of a holiday sale. The dashboard is identical. The consequences are not.
The data was identical; the decision wasn’t only about data. It also turned on things no dashboard holds — how reversible the release is, what it costs to be wrong, how much risk each team is willing to carry, who’s on the other end of a bad deploy. Give the same numbers to two capable teams and they can still, reasonably, disagree.
That’s the part worth sitting with. The disagreement isn’t a failure of measurement. It’s a sign that the last mile of a release decision is judgment — and judgment is exactly what the numbers can’t contain.
Every release is an encounter with the unknown
Bridges are built from static materials with known tolerances. Software is different in kind. It’s continuously changing — requirements shift, dependencies move underneath you, people use it in ways no one designed for — and every deployment creates combinations of behavior that nobody has fully explored. You are never quite shipping the same system twice.
Testing reduces uncertainty — it can’t remove it
So the role of testing was never to eliminate uncertainty. That’s impossible. Its role is to reduce uncertainty enough that a team can make a well-informed release decision. Seen that way, every report, dashboard, defect list, and test run is the same thing in different clothes: an attempt to shrink the unknown before you commit to shipping.
You are not trying to reach certainty. You are trying to be less wrong — deliberately, and with enough evidence to defend the call you make.
That’s not a weakness of testing. It’s the nature of software.
It does change what the evidence is for, though. If no number can hand you the verdict, then measurement was never meant to declare the software ready. Its job is to give whoever decides the clearest possible picture — what’s known, what isn’t, and what’s at stake — and then get out of the way. Surface the evidence. Reduce the uncertainty. Leave the judgment to people.
There’s something freeing in that, once you accept it. If certainty was never on the table, chasing it was only ever going to end in false comfort or paralysis. The honest goal is smaller, and far more reachable: know what you’re shipping, and decide on purpose.
What that changed for us
This realization changed how we thought about building Hawzu. We stopped asking how to produce better dashboards, and started asking a different question: how do software teams actually build confidence from incomplete information?
Work forward from that question and you stop chasing a number that declares the software “ready.” No honest number can. You start connecting the evidence a team already has — what was covered, what ran, what failed, what’s still open — so the people making the call can weigh it and own it.
It’s the other half of an argument we started in our previous essay: if the real job was never managing test cases but answering whether the software is ready to ship, software’s uncertainty is why no report can answer that on your behalf.
Release readiness isn’t declared by software. It’s decided by people using evidence.
