I assume this is written by a UI designer or something, and it certainly feels like "notes" and not a cohesive article. Claiming "The six signals of quality in software" and then listing only user-facing concerns and including subjective items like "Beauty: Is the software as aesthetically pleasing as possible?" is questionable.
I'm interested in quality, but I didn't find these notes enlightening, and couldn't even finish the article.
> 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. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO.
I know where you're going with this, but here's a twist:
A CEO who cares about interface _design_ is path to micromanaging and pain. A CEO should care about interface _designers_, who are (hopefully) the people trained on how do it well.
Even better: CEOs should care about developers with UI/UX skills, because too often CEOs adopt designers like a pet and keep them busy 24/7 asking for mockups.
My assumption when reading that the CEO should care, was that they give those underneath them the time and resources needed to achieve quality because they value it, not that they are necessarily involved in the details.
A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances.
I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better definition of quality. Hardships can come in many forms, and often you're prepared for some of them but not all. Occasionally you'll be prepared for hardships that never occur. There is something to be said for being resilient against the correct kinds of hardships, which is why I'm not entirely pleased with my definition either.
But absence of problems is not it. That might be entirely circumstantial and is therefore orthogonal to quality.
Properly speaking, that would be a characteristic of the entire production process, including the people, rather than a property of the code itself. (At least for now. Stay tuned with AI for further updates.) Still, you'll see it in the code.
Yeah that seems about right! I mean, it is a property of the code itself also, but the code is not the only place quality resides. I think it's fair expect that any piece of software will require updates, and a high quality code base is easier to modify than a poor quality one. But, as you point out, surrounding process, people working on it etc etc etc are also super important.
I think you're circling the definition I most closely align with which was coined by Gerald Weinberg - "Quality is value to some person". You can have the best looking interface and the cleanest codebase, but if nobody is getting value from your software, who cares? If somebody is getting a ton of value from your software they're more forgiving of defects they run into.
There isn't some intrinsic value to software, it's gotta be used by somebody
I'm not sure about that definition. If your software solves a problem that many users face, that makes it useful and, presumably, valuable, but it doesn't mean it's of higher quality than niche software of relatively little use.
i disagree, think about what defines a problem. Not being maintenable, readable, performant etc could be problems or may not be depending on the software requirments.
> Occasionally you'll be prepared for hardships that never occur.
this over-engineering and just as bad as failing to meet a requirement, you're wasting resources that could be spent on something else. In fact, meeting the requirements and only the requirements is requirement #1 ;)
I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.
Right off the bat, I disagree with the assertion that software quality is merely a concept of how it functions now. In reality software is a living thing and quality is so much more than whether there is a glaring issue right now.
Corporate megasoftware suffers from the same structural problems as ancient megafauna; when there is a fixed amount of material to build the organism, it's almost always more efficient to split it into smaller, more coherent, repeatable bodies that project power through coordination, rather than a single large body that imposes its will on the world via sheer weight and size. The bottleneck was, as in the now-extinct branch of evolution, the viability of intelligence in smaller entities; that is now a solved problem. Now we are headed to an Anthropocene of cyberspace, where software is primarily a personal artefact, with optional collaboration, rather than a product designed and distributed from centralized organizations.
> Beliefs about quality I want to disprove... (lists 38 bullets)
Sure you didn't miss one? You can't have an exhaustive list because any of those can be just as true as false depending on the situation.
Instead of picking the ones I disagree with most, I'll just say that low quality is miscommunication. The bugs are a snapshot of the organization.
There are multiple facets to hang concern on that the other stakeholders don't know about or ignore. Your ability to discuss them, plan, and execute is the bottleneck. Everyone has to be on the same page.
This cannot be the sole responsibility of the devs or small isolated teams. Scale is necessary for quality to emerge.
Keep in mind that there are people for whom thinking about quality has been their whole career, for decades. There've been long-running industry studies on software quality that have gathered metrics across thousands of businesses on what works and what doesn't. People have been focusing on quality in businesses in general for centuries. It's not a solved problem, but it has been tackled by experts for a long time. It's a good idea to look to their work first before taking a swing at it yourself.
Personally I find quality to have a fundamental impact on everything every human does. It affects mental state, motivation, affects ability, necessity, and time to do things, creates or reduces costs, availability of resources, clarifies or complicates, makes life easier or harder, etc. It can save or destroy a business, make someone's life feel easy as pie or insanely frustrating. But it's not always easy to do right; you need a system to apply quality intelligently or you risk your efforts being wasted (https://global.toyota/en/company/vision-and-philosophy/produ...).
If thorough testing and 100 experts can’t find a problem, the thing is probably perfect.
If you can get 100 experts to agree on something then you've cracked a much harder problem than software quality.
I assume this is written by a UI designer or something, and it certainly feels like "notes" and not a cohesive article. Claiming "The six signals of quality in software" and then listing only user-facing concerns and including subjective items like "Beauty: Is the software as aesthetically pleasing as possible?" is questionable.
I'm interested in quality, but I didn't find these notes enlightening, and couldn't even finish the article.
Yeah, when a software focuses on beauty I only have to wonder what they sacrificed to achieve it.
> 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. Good interface design needs to be valued by everyone who can affect the work. That includes developers, designers, product managers, and often the CEO.
I know where you're going with this, but here's a twist:
A CEO who cares about interface _design_ is path to micromanaging and pain. A CEO should care about interface _designers_, who are (hopefully) the people trained on how do it well.
Even better: CEOs should care about developers with UI/UX skills, because too often CEOs adopt designers like a pet and keep them busy 24/7 asking for mockups.
My assumption when reading that the CEO should care, was that they give those underneath them the time and resources needed to achieve quality because they value it, not that they are necessarily involved in the details.
A CEO should know when the people working for them are bullshitting them, blowing smoke...
>A CEO who cares about interface _design_ is path to micromanaging and pain.
That's how Apple blew up into a trillion dollar company.
Also how countless other companies didn't.
...while being a painful place to work at, so not really disproving the point.
Plenty of other CEOs have thought the secret to Apple's success was micromanaging like Steve Jobs and been proved very wrong.
The best CEOs hire people smarter than them (in their respective disciplines) rather than assuming they always know best.
I disagree with the initial premise
>Quality is the absence of problems
A low quality code base can be problem free if surrounding circumstances are forgiving enough. Conversely, a high quality codebase can have a lot of problems in difficult circumstances.
I haven't thought about it long enough to have a definition of quality that I'm really happy with, but I think a "resilience to hardships" would be a better definition of quality. Hardships can come in many forms, and often you're prepared for some of them but not all. Occasionally you'll be prepared for hardships that never occur. There is something to be said for being resilient against the correct kinds of hardships, which is why I'm not entirely pleased with my definition either.
But absence of problems is not it. That might be entirely circumstantial and is therefore orthogonal to quality.
I think part of what you're reaching for is the concept of anti-fragility: https://en.wikipedia.org/wiki/Antifragility
Properly speaking, that would be a characteristic of the entire production process, including the people, rather than a property of the code itself. (At least for now. Stay tuned with AI for further updates.) Still, you'll see it in the code.
Yeah that seems about right! I mean, it is a property of the code itself also, but the code is not the only place quality resides. I think it's fair expect that any piece of software will require updates, and a high quality code base is easier to modify than a poor quality one. But, as you point out, surrounding process, people working on it etc etc etc are also super important.
Software very rarely exist in a vacuum
I think you're circling the definition I most closely align with which was coined by Gerald Weinberg - "Quality is value to some person". You can have the best looking interface and the cleanest codebase, but if nobody is getting value from your software, who cares? If somebody is getting a ton of value from your software they're more forgiving of defects they run into.
There isn't some intrinsic value to software, it's gotta be used by somebody
I'm not sure about that definition. If your software solves a problem that many users face, that makes it useful and, presumably, valuable, but it doesn't mean it's of higher quality than niche software of relatively little use.
> But absence of problems is not it.
i disagree, think about what defines a problem. Not being maintenable, readable, performant etc could be problems or may not be depending on the software requirments.
> Occasionally you'll be prepared for hardships that never occur.
this over-engineering and just as bad as failing to meet a requirement, you're wasting resources that could be spent on something else. In fact, meeting the requirements and only the requirements is requirement #1 ;)
> I think a "resilience to hardships" would be a better definition of quality
Does this refer only to program behaviour? I figure readability should count toward quality, but it doesn't directly affect program behaviour.
I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.
Right off the bat, I disagree with the assertion that software quality is merely a concept of how it functions now. In reality software is a living thing and quality is so much more than whether there is a glaring issue right now.
We should look at the nature to learn what quality means. Survive first with whatever it takes. Then if you have comeptition, keep improving.
Corporate megasoftware suffers from the same structural problems as ancient megafauna; when there is a fixed amount of material to build the organism, it's almost always more efficient to split it into smaller, more coherent, repeatable bodies that project power through coordination, rather than a single large body that imposes its will on the world via sheer weight and size. The bottleneck was, as in the now-extinct branch of evolution, the viability of intelligence in smaller entities; that is now a solved problem. Now we are headed to an Anthropocene of cyberspace, where software is primarily a personal artefact, with optional collaboration, rather than a product designed and distributed from centralized organizations.
> The agreed-upon best-designed software in the industry has noticeable problems.
The what? Since when has "the industry" been able to define best-designed, much less agree on it?
Why no security? It's mid-2026, high quality software must be secure by design or you won't be using it.
(Anthony has some great paper solo role playing games on his blog too)
> Beliefs about quality I want to disprove... (lists 38 bullets)
Sure you didn't miss one? You can't have an exhaustive list because any of those can be just as true as false depending on the situation.
Instead of picking the ones I disagree with most, I'll just say that low quality is miscommunication. The bugs are a snapshot of the organization.
There are multiple facets to hang concern on that the other stakeholders don't know about or ignore. Your ability to discuss them, plan, and execute is the bottleneck. Everyone has to be on the same page.
This cannot be the sole responsibility of the devs or small isolated teams. Scale is necessary for quality to emerge.
Keep in mind that there are people for whom thinking about quality has been their whole career, for decades. There've been long-running industry studies on software quality that have gathered metrics across thousands of businesses on what works and what doesn't. People have been focusing on quality in businesses in general for centuries. It's not a solved problem, but it has been tackled by experts for a long time. It's a good idea to look to their work first before taking a swing at it yourself.
Personally I find quality to have a fundamental impact on everything every human does. It affects mental state, motivation, affects ability, necessity, and time to do things, creates or reduces costs, availability of resources, clarifies or complicates, makes life easier or harder, etc. It can save or destroy a business, make someone's life feel easy as pie or insanely frustrating. But it's not always easy to do right; you need a system to apply quality intelligently or you risk your efforts being wasted (https://global.toyota/en/company/vision-and-philosophy/produ...).