In 1902, Hanoi was drowning in rats. The government was getting nervous about plague. Hence, the city put a bounty per rat tail. Suddenly, the system had a way to measure, something you could count, stack, report, and feel good about. Voila! The system worked. Hunters brought tails in, the numbers soared, and the program looked like a win, then reality showed up. Rats were still everywhere, and officials started finding rats alive, without tails. Because once you pay for tails, you create a tail economy. People stop solving the problem and start manufacturing the evidence. Software teams do the same thing, just with prettier dashboards.
We often pursue quality through tangible metrics like code coverage because it is hard to measure the right thing. We choose psedue metrics that might give us some signal. Nevertheless, if you reward a number like code coverage, you will get more code coverage. You will also get tests that assert nothing meaningful, brittle mocks, and a false sense of safety. Your metris can be all green, incidents still happen, and everyone is confused you were supposed do well.
The emphasis on numbers might lead us astray from the essence of what true quality signifies. We often forget that metrics are indicators not guarantees, and treating them as the final measure of quality can create a dangerous illusion of progress. Every project encounters its own set of hurdles. Be it tight deadlines, evolving requirements, or sneaky bugs. Amid these challenges, upholding your high-quality bar is really hard.
Metrics are useful indicators; however, they are not guarantees. Real quality shows up in judgment, collaboration, and context, especially when deadlines, shifting requirements, and production weirdness start applying pressure.
What Metrics Don’t Capture
Each iteration in a software project is another round of tail counting. You push a change, you watch the the leaderboard, you check the numbers you chose to represent quality: coverage, bugs, latency, error rate, story points, whatever your org worships this quarter. And just like Hanoi, the moment those numbers become targets, people learn to feed the metric. Nobody is evil, it's just that incentives migth be wrong.
Teams will write tests that execute the lines without proving the behaviour. They will mock away the part most likely to fail. They will split work into smaller pieces because throughput looks better that way. Risky refactors will keep getting postponed because they might hurt the stability numbers for a quarter. The metrics improve, but the system underneath them stays exactly where it was.
This is the problem with measuring engineering work. The variables that matter most usually sit behind the number. You need the context around a change, the judgment to know whether a test proves anything, and the intuition to distrust a green build when the change still feels unsafe. You need engineers who can see how real users will break the assumptions nobody wrote down. None of that fits cleanly into a dashboard, but that does not make it less real.
The variables you already measure still contribute. They are useful sensors, but they are not the craft. The craft is noticing what the metric fails to see and refusing to let a count masquerade as quality.
What matters most is usually off-dashboard: developer intuition, context around real user needs, forward thinking about stability, and a team’s ability to learn from past iterations and mistakes. These shape the final product far more than any single percentage ever could.
Beyond Numbers: Quality in Software Engineering
Looking Beyond the Numbers
When a team is encouraged to look beyond numerical targets, their questions change. They stop asking, “How do we get this number up?” and start asking, “What will fail in the real world?”
They start looking at impact instead of output. Can users complete the job without unnecessary friction? Does the system behave predictably under load? Can the codebase be changed without fear? The team still tracks metrics, but the metrics serve the work, not the other way around.
You can have bug-free code and still ship a product users hate. You can reach 100% code coverage and still miss the failure mode that matters. The dashboard may look perfect while the product underneath it remains difficult to use, fragile to change, or expensive to operate.
The goal is not a perfect outcome. The goal is software that survives contact with reality.
In practice, this means asking better questions. Does this change make the user’s job easier? Does the system degrade gracefully? Can the team maintain it without heroics? The answers will rarely fit into a single percentage, but they will tell you far more about the quality of the system.
All in All
Quality is not a number you achieve once. It is the behaviour a system keeps when the load increases, assumptions fail, and people start taking shortcuts.
Usability, resilience, maintainability, and clarity are harder to measure because they only become visible through use. A bamboo plan can tell you that the tests passed. It cannot tell you whether the change made the system easier to trust, easier to operate, or easier to change six months later.
Metrics still matter, but only as signals. The moment the number becomes the target, the work starts bending around it. Teams collect tails because tails are easy to count, while the rats move somewhere the dashboard cannot see.
So the useful question is not whether one metric improved. It is whether the signals, taken together, give you enough reason to believe the system did.