Notes on Software Quality

Source: https://anthonyhobday.com/blog/20260410 (Anthony Hobday, 2026-04-10) Fetched via defuddle on 2026-07-18. HN discussion: https://news.ycombinator.com/item?id=48821441

How I think about quality

Quality is the absence of problems

"The absence of problems" is the best definition I can come up with for quality.

The most practical way to measure quality is to test with many different people, and have many experts take a look. If thorough testing and 100 experts can't find a problem, the thing is probably perfect.

Quality is a spectrum up to "perfection"

Perfection is impossible. The agreed-upon best-designed software in the industry has noticeable problems. But the closer you can get, the better.

The closer you try to get to perfection, the harder it is. This is the same "diminishing returns" effect you'll see anywhere quality is involved.

Quality relies on the organisation

Leadership and culture both define and allow quality. Even if they don't believe they do. Even if they haven't thought about it. Their actions and beliefs will either enable or limit quality.

Quality is a result of ability and appetite. Does the organisation have people who can produce high quality (ability)? And does the organisation allow quality to be achieved (appetite)?

~100% of the time I've seen an organisation make high quality software, it is because the leaders wanted it. If the leaders don't want quality, it will be much harder.

But don't forget that whatever you work on, there is an amount of quality you personally can achieve. Even in the most rigid design-system-controlled interface, there are still higher quality and lower quality choices you can make.

An organisation can set objective measures of quality (e.g. bugs reported). Hopefully those objective measures don't blind the organisation to the subjective measures (e.g. "does an expert think this is high quality?").

Quality gets harder with scale

The larger the organisation or software, the harder quality is. High quality is impossible past a certain point of scale. Some organisations are incapable of making high quality software.

Importantly, this is a natural result of scale. It's not a complaint or a problem to be solved. It cannot be solved. It's a trade-off, like almost everything else in software.

Quality is not necessary, but ideal

I wish every organisation cared about quality. It's clear that many of them don't, and don't need to. Many commercially successful organisations don't prioritise quality.

But quality is ideal. Everyone wants to live in a higher-quality world. It feels good to create quality. Things last longer if they're higher quality. And over the long term, commercial success is harder if people realise your brand doesn't represent quality.

Universal signals of quality

These are the signals of quality that I've found apply to everything. People and artefacts.

Appearance: In (over)simple terms, the more beautiful something is, the higher quality we think it is. Beauty requires effort, and so does quality in general. Any evidence that we have put care into something is evidence of further care.
Association: We judge whether something is high quality by what it is associated with. A common approach to this is social proof. We judge a thing by the company it keeps.
Cost: If something costs more, we might assume that is because it is worth more. But "cost" does not have to mean "money". If something takes more time, we might assume it is of higher quality.
Performance: Could be quantitative like "top speed", or qualitative like "how does it make me feel". If appearance is "how it looks", performance is "how it does".

The six signals of quality in software

Reliability: Does the software technically perform as expected, all of the time? No bugs, no downtime, no errors.
Speed: Does the software react to input instantly, or as near as practically possible?
Clarity: Does the person using the software understand everything?
Efficacy: Can the person do what they need to do with the software?
Efficiency: Can the person do what they need to do with the software as easily as possible?
Beauty: Is the software as aesthetically pleasing as possible?

The benefits of software quality

Attract employees: People want to work for companies that care about quality.
Satisfaction as creators.
Fight fewer fires: fewer bugs, fewer reliability issues.
Fight software entropy: a commitment to quality pushes back against bloat.
Less employee churn.
Easier to sell: word of mouth does some of the marketing.
Attract users.
Users become fans.
A competitive moat: quality is hard, competitors probably won't put the effort in.
Make more money: people universally pay more for quality.
Beauty improves society.
Inspire quality in others.
Leave a legacy: people talk about good software for decades.

Beliefs about quality I want to disprove

Hobday lists 38 beliefs he holds but wishes were false. Selected:

Quality is easiest when one person can keep the whole interface in their head.
The more people who work on some software, the harder high quality is.
Quality depends on permission from whoever is most powerful at an organisation.
Quality cannot be a bottom-up effort, driven only by the people who do the work.
High quality always requires a sacrifice of something (scope, money, growth, time).
High quality always requires someone with a strong personal obsession with it.
Some organisational cultures are incapable of high quality.
At a certain size of organisation, and of software, high quality is impossible.
If something is low quality in some software, it's usually a reliable sign that other things are low quality.
Focus on quality has diminishing returns (much more effort for "90%" than "80%").
The systems in place to help create software (e.g. design systems) can also hurt quality.
People associate expressive visual styles, high cost, and hype/community interest with quality.
There are many ways to compete that cost less than quality (features, price, sales experience).
Novelty is more immediately attractive to people than high quality.
High quality is often not noticed until later.
Organisations and people will almost never tell the truth about the low quality of their products.

Quality is impossible at scale

Good interface design becomes harder as software grows. Eventually, world-class interface design is impossible.

There are too many relationships to manage

Good interface design is coherent — the relationships between all the things in the interface work well. But as the number of things goes up, the number of relationships goes up even faster. Eventually it's impossible to properly consider all of those relationships. This applies to people too: the more people who work on software, the harder it is to manage the relationships between them. You can manage this with stricter processes, but eventually you'll spend more time on process than on design.

Some people don't care enough

The more people you hire, the more likely you are to hire people who don't care enough about good interface design. It needs to be valued by everyone who can affect the work: developers, designers, product managers, and often the CEO.

Some commercial goals hurt good design

If a company wants some numbers to go up for commercial reasons, this often hurts interface design quality. Adding more advertising can help profitability but makes the interface worse. Adding requested features grows the product but often each feature makes the interface worse.

Anecdotal evidence that quality is impossible at scale

A long collection of quotes from practitioners, all pointing at the same inverse correlation between team/product size and quality. Highlights:

Patrick McKenzie (Stripe): even Stripe is "actively dissatisfied with where quality is at the moment".
Jordan Singer: "the attention to detail is inversely proportional to the size of the team".
George Kedenburg III: "craft just becomes more and more expensive the bigger your product/team is" — and his essay "The Cost of Craft" ("It appears inevitable that all digital products must eventually trade craft for scale").
The Browser Company ("Optimizing For Feelings"): software became one-size-fits-all, "the hand of the artist gave way to the whims of the algorithm".
David Khourshid (Stately): adding a single feature can introduce an exponentially greater number of ways an app can be used.
Packy McCormick ("Indistinguishable from Magic"): startups create magic, monetise it, then technical debt and public-market pressure turn them into "Big Muggle Companies" that can no longer conjure magic.
Paul Graham: "Google has become terminally bureaucratic".
Patrick Collison: big companies "can't turn capital into good software"; this organisational transformation "is just so profoundly hard".
Dan Luu: small firms can sustain a culture of excellence without heavyweight process, but big tech can't after hypergrowth. Also: successful companies "route around making a product that works" (the MongoDB example — loud bogus performance/correctness claims beat actually being correct).
Steve Jobs (1995, "Triumph of the Nerds"): monopolies let sales/marketing people take over from product people, and "the companies forget what it means to make great products".
Gergely Orosz: at big tech, incentives reward impact/revenue at scale, not fixing low-impact issues; fixing one-off issues is one of the most expensive things to do.
Cory Doctorow: the enshittification arc — good to users, then abuse users for business customers, then abuse business customers for themselves, then die.
Nick Lockwood: development is like Zeno's paradox — effort rises exponentially, you never reach completion. This applies fractally to every feature.
Adam Michela: the ~30-person moment (5-10 engineers, 2 designers) is the quality sweet spot.
Alexandr Wang: teams >8 people ship less — not just per capita, less overall.
Karri Saarinen (Linear): as companies scale they decide by measurement, and quality can't be easily measured, so they give up on it.
Craig Mod, Tim Bradshaw (FT): macOS Finder/Safari/Mail instability, Dropbox and Spotify bloat — super-apps solve a problem for the company, not the customer.

Companies with dedicated quality efforts

Named programs Hobday tracks:

Automattic: a Chief Quality Officer (Lance Willett), C-suite, "full-stack leader" running a QualityOps team.
GitLab: "UX Paper Cuts" team — fixes small usability issues across the product, does not take on new feature work.
HubSpot: "Cohesion Studio" — a horizontal layer between the design system team and product teams, unifying end-to-end journeys.
Linear: a dedicated "polishing season" (Dec 2022), a policy that bugs are prioritised over everything else, and "Quality Wednesdays" where each member shows one thing they improved.
Meta: Ron Goldin and colleagues defined a numerical "Craft score" for key journeys.
Microsoft: after outcry over Windows 11 quality, a plan focused on performance, reliability, well-crafted experiences.
Operate: a "Give a Damn" initiative — dedicated time to sweat the details.
Shopify: a team looking horizontally across Shopify admin at quality issues.
Sonos: a "Quality Ombudsperson" reporting to executive leadership and the board.
Stripe: hired Malthe Sigurdsson as "Head of Craft" on Katie Dill's team.
Zed: a twice-yearly "Quality Week" — halt features, work solely on user pain points, reduce cases where Zed can panic.

Interface quality of life improvements

A concrete list of 20 micro-details. Selected:

Generous mouse paths in nested menus (menu doesn't close if the mouse strays outside its boundary).
Coyote time for keyboard shortcuts (a multi-key shortcut isn't cancelled the instant you release the wrong key first).
Stretch/bounce motion at the end of scrolling list views.
Smooth, fast expand/collapse animations, starting from the direction of the triggering element.
Optical adjustment of visually unbalanced elements so they look properly aligned.
When an element enters edit mode, keep its text in the same place.
When items are added/removed from a list, maintain subjective scroll position so visible elements stay put.
Open context menus so the actions land in the same place relative to the cursor.
When a click opens a new interface under the cursor, don't put something risky there in case of an accidental second click.
Object permanence: elements shared across views persist through transitions.
Unless explicitly requested, information a person entered is never lost when they leave the screen.
Delay opening a tooltip, but if the mouse moves to a neighbouring element with a tooltip, show that one instantly.

Notable HN discussion points (id=48821441)

The comments largely push back on the opening definition and the scale claim.

Competing definitions of quality offered: Gerald Weinberg's "quality is value to some person" (quietkoala, satisfice); "resilience to hardships" / anti-fragility (amarant, jerf); "maintainability" (jongjong); the ISO 25010 standard and DORA capabilities (Lutger, j0llyj0hns0n) as more rigorous framings than inventing your own signals.
satisfice: "quality is the absence of problems" is a reification fallacy — a problem is only a problem because someone decides it is; the question is WHO matters and how they FEEL.
Long thread on whether unused software can have quality: MaxBarraclough argues quality is roughly intrinsic to a product (Apollo Guidance Computer software isn't low quality just because nobody runs it now); scott_w argues quality is unmeasurable until real use.
On the CEO point (manoDev): a CEO who cares about interface design leads to micromanaging; better that a CEO cares about designers and gives them time and resources. Counter: Jobs-style micromanagement built a trillion-dollar Apple; counter-counter: most CEOs who copied it failed.
Several note security is conspicuously absent from the six signals. arscan argues security runs in opposition to usability/interoperability and is a value not universally held, so its omission is defensible.
p1necone: large orgs can hit high quality, but only via small autonomous teams per product — and the "sensible" consolidation moves (shared component libraries, shared implementations) are what kill it.
chickensong: the piece reads as "notes", not a cohesive article; "six signals" listing only user-facing concerns and subjective items like beauty is questionable.
Recurring pointers to prior art: Walter Shewhart's 1931 work, the Toyota Production System, "Zen and the Art of Motorcycle Maintenance", and the point that quality has been studied rigorously for decades (0xbadcafebee).