News

Software Quality Isn't a Feature, It's a Culture

A practical breakdown of what software quality really means, why it's so hard at scale, and why most organisations don't even try.

July 7, 2026· 3 min read
Software Quality Isn't a Feature, It's a Culture

Anthony Hobday has published a thoughtful essay on software quality that cuts through the usual platitudes. His central thesis: quality is the absence of problems, and it's a spectrum that asymptotically approaches an impossible perfection. The closer you get, the harder it gets — classic diminishing returns.

What quality actually looks like in software

Hobday identifies six signals that collectively define software quality: reliability (no bugs, no downtime), speed (instant or near-instant response), clarity (the user understands everything), efficacy (the user can do what they need), efficiency (they can do it as easily as possible), and beauty (aesthetic polish). These are not optional extras; they are the dimensions against which every piece of software should be measured.

He also notes four universal signals that apply beyond software: appearance, association (social proof), cost (time or money spent implies value), and performance (how well it does its job). These are the lenses through which humans judge quality everywhere, and ignoring them in your product is a mistake.

Why most organisations fail at quality

The uncomfortable truth is that quality is a function of leadership and culture. If the people at the top don't actively want it, it won't happen. Hobday argues that ~100% of high-quality software he's seen came from organisations where leaders explicitly prioritised it. The rest is just damage control.

Scale makes quality exponentially harder. Past a certain organisational size, high quality becomes impossible — not because of incompetence, but because of natural entropy. This isn't a solvable problem; it's a trade-off. Some companies are simply incapable of producing high-quality software, and they should acknowledge that instead of pretending otherwise.

The business case for quality

Hobday lists thirteen benefits, but the ones that matter to working engineers are: fewer fires to fight, lower employee churn, easier recruiting, stronger word-of-mouth marketing, and a genuine competitive moat. Quality is hard; your competitors probably won't do it. That's the whole point.

He also pushes back on the idea that quality is a luxury only for well-funded teams. Even within a rigid design system or a constrained budget, there are higher- and lower-quality choices you can make every day. The gap between a conscientious engineer and an indifferent one is visible in the product.

The full post is worth reading for anyone who's ever been told to ship faster and fix it later. Hobday's perspective is refreshingly free of vendor shilling or framework hype — just a clear-eyed look at what quality costs and why it's worth paying.