Notes on Software Quality (Hobday)

Anthony Hobday, a designer who writes mostly about visual design, collected his working notes on what software quality is and why organisations lose it. The page is exactly that — notes, not an argued essay — and the HN thread spends most of its energy contesting the opening definition and the central claim about scale.

His definition and signals

Hobday's working definition is "quality is the absence of problems." His test for it is empirical: if thorough testing plus 100 experts can't find a problem, the thing is probably perfect. Perfection is impossible, so quality is a spectrum you approach with diminishing returns — getting from "80%" to "90%" costs far more than getting to "80%" did.

He separates two layers of signal. The universal signals that make people judge something as high quality are appearance, association (social proof — a thing is judged by the company it keeps), cost (including time, not just money), and performance. These are proxies people read, not quality itself. The signals that constitute quality in software are six: reliability (no bugs or downtime), speed (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 (it's as aesthetically pleasing as possible).

Two things are conspicuously missing from that list, and HN caught both. Security appears nowhere — one commenter (arscan) defends the omission on the grounds that security actively trades off against usability and interoperability and is a value not everyone holds, so it belongs to a different axis than these six. Maintainability is also absent, which several commenters treat as the real marker of quality, since maintainable code is what lets you keep the other signals from decaying.

Quality is organisational, and dies at scale

The load-bearing claim is that quality is a property of the organisation, not the code. It comes from ability (do you have people who can produce it) and appetite (does the organisation let them). In Hobday's experience, ~100% of the time an organisation ships high-quality software it's because the leaders wanted it. He also lists 38 beliefs he holds and wishes were false — most of them variations on "the more people who touch the software, the harder quality gets," "quality needs permission from the top," and "design systems and other process meant to help can also hurt."

His argument for why scale kills quality is combinatorial. Coherent interface design means the relationships between elements all work; as the number of elements grows, the number of relationships grows faster, until no one can hold them. The same math applies to people — more people means more relationships to manage, more gets lost in translation, and process eventually costs more than it buys. Add that larger hiring pools dilute the share of people who care, and that commercial goals (ads, requested features) each individually degrade the interface, and quality becomes impossible past some size. He frames this as a trade-off inherent to scale, not a bug to be fixed.

Most of the page is then a wall of quotes backing the small-teams-only thesis: Patrick Collison ("big companies can't turn capital into good software"), Dan Luu (excellence culture survives in small firms but not after hypergrowth; companies profitably "route around making a product that works"), Steve Jobs on monopolies letting sales/marketing displace product people, Gergely Orosz on incentives that never reward fixing low-impact issues, Cory Doctorow's enshittification arc, and roughly twenty more designers converging on "there's an inverse correlation between headcount and end-user quality." Adam Michela pins the sweet spot at ~30 people (5-10 engineers, 2 designers). This is where the notes are weakest as an argument — it's argument by testimonial rather than evidence, the same quote stacked twenty ways, and HN's p1necone offers the obvious counter: large orgs can hit quality via small autonomous per-product teams, and it's the "sensible" consolidation moves (shared component libraries, shared implementations) that actually kill it.

The parts worth keeping

Two sections are more concrete than the thesis. Hobday catalogues real, named quality programs at companies that put structure behind the intent rather than just claiming to care: Linear's bugs-before-everything policy and "Quality Wednesdays," Zed's twice-yearly "Quality Week" (halt features, reduce cases where the editor can panic), GitLab's "UX Paper Cuts" team, Stripe's "Head of Craft," Automattic's Chief Quality Officer, Sonos's "Quality Ombudsperson," plus Meta, Microsoft, HubSpot, and Shopify efforts. The pattern across them is a horizontal team with permission to fix small things and explicitly no feature quota.

The other is a list of 20 interface quality-of-life details — the kind of micro-craft that's invisible when present and grating when absent: generous mouse paths in nested menus, "coyote time" for keyboard shortcuts (a chord isn't cancelled the instant you release the wrong key first), keeping entered data on screen exit, object permanence for elements shared across views, opening context menus so actions land in the same spot relative to the cursor, and delaying a tooltip but showing a neighbour's instantly once one is open.

Where the definition breaks

The HN discussion is a useful corrective to the opening line. "Absence of problems" is a reification fallacy (satisfice): a problem is only a problem because someone decided it is, which pushes the real question back onto who matters and how they feel — closer to Gerald Weinberg's "quality is value to some person." Others reach for "resilience to hardships" and anti-fragility (a high-quality codebase is one that's cheap to change when circumstances get hard), or point out that this ground was covered rigorously long ago — Walter Shewhart's 1931 work, the Toyota Production System, ISO 25010's stakeholder-value model, and DORA's empirical research all predate inventing your own six signals.

Relation to other pages

The scale argument rhymes with a theme running through the wiki's coding-agent critiques. peril-of-laziness-lost makes a structurally identical point about a different actor: quality (there, simplicity) erodes when the thing generating code has no constraint forcing it to care — for Cantrill it's LLMs lacking human laziness; for Hobday it's large organisations lacking appetite. clean-code-coding-agents argues code structure matters more with agents because messy code wastes finite context — a maintainability-as-quality position that fills the gap HN flagged in Hobday's six signals. And no-silver-bullet-llms shares the skeptic's move of insisting quality is bounded by structural facts (there, Brooks' essential complexity; here, the combinatorics of relationships) rather than solvable by effort or tooling.