Notes on Software Quality

A few weeks ago I opened three apps I use every day and each one made me wait. Not for network. For nothing. A menu that took 400ms to animate open, a settings page that flashed white before it painted, a list that jumped under my finger as new items loaded in. None of these are bugs anyone would file. All three products are made by large, well-funded companies with more designers and engineers than I will ever work alongside. And all three felt worse than they did two years ago.

That gap has been on my mind for most of my career, and the best framing I have found for it comes from Anthony Hobday's Notes on software quality. I want to write down how I think about it, because the conclusion is uncomfortable and most engineers never say it out loud.

Quality is the absence of problems

The cleanest definition of quality I know is negative. A thing is high quality when you cannot find a problem with it. Not when it has more features, not when it is more clever, not when the marketing page is prettier. When many different people use it and many experts inspect it and nobody can point at something that is wrong, it is close to perfect.

That definition is useful because it tells you how to measure quality, which is the part people skip. You measure it by having lots of people try to break it and lots of experts look hard at it. There is no metric that substitutes for this. You can count bug reports and crash rates and p95 latency, and you should, but those numbers describe a floor. They tell you when something is obviously broken. They do not tell you whether an expert would look at your product and wince.

Perfection is not reachable. The best-designed software in the world has papercuts if you look for long enough. Quality is a spectrum that runs up toward a ceiling you never touch, and every step closer costs more than the last. Getting to "pretty good" is cheap. Getting from pretty good to genuinely excellent is where most of the money and most of the pain live.

The six things worth checking

Whether you are reviewing a pull request or just judging an app you downloaded, you are really asking a handful of separate questions. Does it do what it claims every single time, with no errors and no downtime. Does it react instantly, and where it genuinely cannot be instant, is it as fast as the constraints allow. Does the person using it understand what is happening. Can they do the thing they came to do. Can they do it with as little friction as possible. And does it look like someone cared.

Reliability, speed, clarity, efficacy, efficiency, beauty. They are not the same axis and a product can be strong on some and weak on others. Plenty of "reliable" enterprise software is a misery to use because it scores zero on clarity and efficiency. Plenty of beautiful apps fall apart the moment you push on them. The reason I keep the list explicit is that teams tend to over-index on the one or two dimensions they can measure and quietly ignore the rest.

There is also a signal worth naming: if one part of a product is sloppy, the rest usually is too. A misaligned button or a laggy transition is rarely an isolated miss. It is evidence about the culture that shipped it. Spot one corner cut and it is a safe bet the corners you cannot see were cut as well.

Quality is decided above your pay grade

Here is the uncomfortable part. Look at the products that consistently ship at a high bar and the common thread is not raw talent, it is that leadership wanted quality and protected the time to reach it. When a capable team ships mediocre software, it is rarely because the engineers could not do better. It is because the organisation around them did not have the appetite. This is as much about how leaders operate as it is about engineering.

Quality needs two things at once: ability and appetite. Ability is whether you have people who can produce excellent work. Appetite is whether the organisation will let them. Most companies have more ability sitting idle than they realise. Cemre Güngör, a PM who worked on Instagram, put it well: big companies hire expensive senior designers and still ship poor design, because the hard problem was never talent, it was the incentives and the metric-chasing stifling the talent that is already there.

This is why "just hire good people" is not a strategy. Good people in an organisation that rewards shipping features over polishing them will ship features and let the polish rot. The incentive wins. Gergely Orosz has written about how nobody at a large tech company gets promoted for fixing a papercut that annoys 0.002% of users, and fixing one-off issues is one of the most expensive things a team can do, so it simply does not happen. The system is working as designed. That is the frustrating part.

Quality is impossible at scale

I have come around to a hard version of this claim, and I think it is true: past a certain size, world-class quality becomes impossible. Not difficult. Impossible.

The mechanism is coherence. Good design is coherent, which means the relationships between all the parts hold together. But when you double the number of things in a product, you more than double the number of relationships between them. Add enough surface area and no single person can hold the whole thing in their head anymore, and once nobody can hold it in their head, nobody can keep it coherent. The same math applies to people. Ten people can stay in sync almost for free. Ten thousand cannot, no matter how good your process is, and if you add enough process to compensate, you now spend more time on process than on the work.

You do not have to take my word for it. Patrick Collison, who runs a company famous for caring about this, said big companies mostly cannot turn capital into good software and it would be immensely valuable if they could, but they don't. Dan Luu, who has studied engineering culture more carefully than almost anyone, found that small firms with a culture of excellence exist and persist without heavyweight process, but that this cannot survive the hypergrowth phase every big tech company goes through. George Kedenburg III watched it happen at Instagram and wrote that the cost of craft rises with each additional person, and that trading craft for scale looks inevitable. Karri Saarinen at Linear said companies usually just give up on quality as they grow, because quality resists being measured and scaled organisations run on measurement.

The important thing is that this is not a villain story. Nobody is being lazy. It is a structural trade-off, the same kind of trade-off you make everywhere else in software. Scale buys you reach and revenue and pays for it in coherence. You cannot have all three maxed out at once.

What you can still do

If it stopped there this would be a depressing article, so here is the other half. The size of the organisation caps how good the product can be. It does not cap how good your part can be. Whatever you are working on, even inside the most locked-down design system, there are higher-quality and lower-quality choices in front of you, and you get to make them.

A single engineer can raise the bar on one surface, an onboarding flow, a settings screen, a public API, and watch it quietly become the reference other people copy. That happens more often than you would expect. Quality is contagious in the same way sloppiness is. You do not need permission to make the thing you own excellent. You need permission to make the whole product excellent, and those are different asks.

A few companies are trying to buy back coherence with structure, and it is worth watching what they do. Linear runs "Quality Wednesdays" where everyone shows one thing they made slightly better that week, and treats bugs as drop-everything work. Zed halts feature work twice a year for a "Quality Week" aimed at pain points and crashes. GitLab has a standing "UX Paper Cuts" team that does nothing but fix small usability issues across the product. Automattic hired a Chief Quality Officer who sits in the C-suite. Microsoft, after public anger about Windows 11, published a commitment to reliability and performance. None of these fully solve the scale problem, because it cannot be solved. What they do is push back on the entropy hard enough to slow it down, and that is the realistic goal.

The part I have not resolved

What I keep circling is that everyone agrees quality is good and it is still hard to get anyone to fund it. People who obsess over quality in their own lives, the coffee, the tools, the house, will tolerate shipping software they would be embarrassed to have their name on, because the organisation does not reward the alternative. Novelty is more attractive in the moment than craft, growth pays better than polish, and nobody thanks you for the bug that never happened. Meanwhile the companies that do care almost never say the truth about the quality of their products, so you are left inferring the culture from the papercuts.

I do not have a clean ending for this, and I have stopped looking for one. What I have settled on is smaller and more useful: make the thing you own good, refuse to let one cut corner become two, and pick who you work for partly on whether they have the appetite, because you cannot supply it for them. The scale problem is real and it is not yours to fix. The corner in front of you is.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and engineering decisions on Gazar Breakpoint on YouTube.

If you are an engineer targeting staff or principal and want this kind of thinking applied to your actual situation, I do 1:1 mentorship.