Sometimes yes. My dentist explained she recommended Colgate because none of their 30 equal choices used to contain stannous floride, so it was easier to shop by brand than search for which ingredient to avoid specifically amongst the competitors 30 choices
Oh but it does, they just don't give the US access to the good stuff. Sensodyne Repair & Protect with NovaMin is available in Europe, but because American Crapitalism, aka money aka FDA, you can't get it in the US.
I eat a quarter of a tube of toothpaste per day. Other than the weight loss, hair loss and reduction in bowel control, I have not noticed any negative side effects. Helps keep my insides clean.
Take curl, it has had many more than 100 experts going through it over the years, and yet with new tooling (AI) they located a bunch of other issues. Perfection in software does not exist, but that's fine as long as you're aware.
(in the case of curl, any security issues inside the library should be mitigated by its environment)
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 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.
OP didn’t say “little-used” software, they said “nobody,” and I think this was meant to be taken literally in this context. Software that has 0 users is of no use to anyone by definition.
If you are using quality as a metric then something having more quality would mean it having more value to more people. So a piece of software working 95% of the time to 1 mil users is deemed "of higher quality" by this metric than a piece of software working 100% of the time to 1k users. I don't think this definition for quality is good at all
You’re still missing the point: software used by LITERALLY 0 PEOPLE cannot be useful. Whether it’s well written is completely irrelevant because it, by definition, is providing value to NOBODY.
Agreed. The quality of a software package doesn't change when its last user stops using it. We don't say that the Apollo Guidance Computer software is of low quality these days given that nobody's using it.
Software quality is, roughly speaking, intrinsic to a software product. Its usefulness is not intrinsic, it can depend on any number of external factors. Quality is not the same as usefulness.
But if it’s unused then how does one measure quality? We can write all the tests, look at architecture patterns, etc. but software truly is a case of “the proof of the pudding is in the eating.”
But that’s not my argument at all. I’m saying that quality is impossible to measure if 0 people use it. Once you go above 0, it can be measured and it’s not necessarily related to how many people use it.
It is still possible to measure the quality of software (or other products) simply by defining a metric that proves quality and testing for it
If I were to write 2 simple functions that reverse an array, and one successfully reverses an array and the other just randomizes it - despite never using this function, we could all agree that function 1 is of higher quality than function 2.
This is an extreme example but the same can be done for, lets say, speed or error handling.
While I think the example is too fake as to be too useful, let's take it. While we could read the code and say that one appears to achieve the job we want and the other doesn't; you don't know if the one that apparently does the job actually does the job until you put it into real-world use. You can't know it'll run with acceptable speed, edge-cases, etc. until you actually run the code in production!
If that code never goes into production with real customer use-cases, everything we say about its quality (on any metric) is 100% theoretical! We can try to replicate that environment, and we should, but until it's actually used, we can't truly know.
Yeah I think the absence of problems is one way to think about it but it's closer to half the equation.
Quality is a set of characteristics that are ultimately decided by the user, and not every user will agree on what those characteristics should be. This is why user testing of all sorts is very valuable.
You have to go back to Walter Shewhart's work and writings while at Bell Labs. In 1931's 'Economic Control of Quality of a Manufactured Product' he draws a line between 'a thing' and the human experience of it, drawing heavily from the philosophy of C.I. Lewis:
"There are two common aspects of quality: one of them has to do with the consideration of the quality of a thing as an objective reality independent of the existence of man. The other has to do with what we think, feel or sense as a result of the objective reality. In other words, there is a subjective side of quality."
He draws a line between objective quality (the measurable, physical things) and subjective quality (the human relationship to those properties).
Later in 1939's 'Statistical Method from the Viewpoint of Quality Control' he gives a good example:
"Let us take a very simple example. Suppose we consider the quality of a glass of water. We may list some of its characteristics as follows: temperature, volume, chemical purity, taste, clarity, and color. If we look at any one of these characteristics, say temperature, we see that it is impossible to specify the temperature of a glass of water to the last degree of accuracy."
I would argue this is the standard to go for when looking for a definition. Ask yourself what makes a quality glass of water and you'll immediately realize you need to ask 'according to who?'.
The transcendental perspective deals with the metaphysical aspect of quality. In this view of quality, it is "something toward which we strive as an ideal, but may never implement completely". It can hardly be defined, but is similar to what a federal judge once commented about obscenity: "I know it when I see it".
The user perspective is concerned with the appropriateness of the product for a given context of use. Whereas the transcendental view is ethereal, the user view is more concrete, grounded in the product characteristics that meet user's needs.
The manufacturing perspective represents quality as conformance to requirements. This aspect of quality is stressed by standards such as ISO 9001, which defines quality as "the degree to which a set of inherent characteristics fulfills requirements".
The product perspective implies that quality can be appreciated by measuring the inherent characteristics of the product.
The final perspective of quality is value-based. This perspective recognizes that the different perspectives of quality may have different importance, or value, to various stakeholders.
I once saw an organization that migrated from Weblogic to Kubernetes, keeping the rule to have a least two instances of each app but forgetting that that their Weblogic had distributed transactions and without implementing something similar in Kubernetes.
They happily serve users, helped by low traffic and low expectations. Occasional data corruption and race conditions give work to the support maintenance teams.
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 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.
> 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.
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.
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...).
> It is based on the premise of making work easier for workers. The objective is to thoroughly eliminate waste and shorten lead times to deliver vehicles to customers quickly, at a low cost, and with high quality.
^ = from your linked Toyota Production System philosophy
Thanks for that link! I find those two early sentences to be an insightful and relatively complete loop of process.
When considering using automation or ~A.I. we can easily ask: which part of this loop is our addition improving (or messing up)? Where is the balance that works?
As you point out, answering these what-works/quality questions are not solved problems and expertise is needful, but careful consideration does not seem to be a popular mode in our age of fountaining funny money and magic genies.
I grew up in the '60s where the science fiction/future was always: march of progress and you'll have so much time and choices! Now I am in the future and the reality is close to: who has the time?
More insidiously/invisibly: you have plenty of time for endless momentary thrills, but no one has time to make things better.
Once upon a time there were customer complaint departments and the Production System would get fixed. Then it became suggestion boxes and returns. Then pleading for a Return Merchandise Authorization. Then it's your call is valuable to us recordings before click call hangups. Oops, unhappy customer?--give 'em a coupon to keep up the addiction, it's cheaper than Quality Control.
The latest devolution seems like fire the workers but use AI to mesmerize customers, or just mind control ~investors and ~regulators, since who needs cover-our-costs-paying-customers anyway?
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.
I tend to agree with a few others here, Quality is not just the absence of problems, it is something deeper.
For me it means care and attention were paid while developing, the rough edges have been smoothed off for want of a better phrase. This doesn't mean using the latest and greatest framework or library, usually quality will come from a deep understanding of the basics and concepts like design patterns .
You can spot quality code in the same way to can tell a fake Rolex from a real one but the quality of the movement.
That's a "yes and no" thing. Handmade quality, yes, but some companies get pretty good at finding a "sweet spot," between better-than-average quality, and "Rolls Royce" quality.
Source: I worked for a company that was pretty much renowned for Quality. We made stuff that is pretty near the top shelf, but still a rung or two under the top.
It's not easy.
Also, customers are willing to pay for garbage. As long as that continues, garbage producers will drive quality producers out of business.
"Quality is the absence of problems" is an example of the reification fallacy, because a problem is not a fixed thing. A problem is only a problem because someone decides it is so.
This is why a better definition is "quality is value to some person who matters." This definition instantly places you at the crux of the matter, which is not about a state of the world or of your product in the world, but rather about WHO matters and how they FEEL about your product.
A more rigorous definition of software quality can be found in ISO 25010.
> The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders' needs (functionality, performance, security, maintainability, etc.) are precisely what is represented in the quality model...
Quality software meets its requirements. Both functional and non-functional. Of course our industry still cannot quantify non-functional requirements, or discover a way to predictably implement functional requirements.
So all that remains for our so called “engineering” discipline, is an answer that says something that doesn't break a lot.
> 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.
I also think of Quality as “usable,” “discoverable,” “pleasant,” and “accessible.” He covers them, in some fashion.
Some of these are difficult to quantify, but are often the difference between success or failure, in the market.
I constantly encounter “dead” software. Software that is correct, performant, awesome (in some cases), but something that I don’t “want” to use. A “necessary evil.”
That kind of statement doesn’t fly well, in a community of “Inspector 34”s, but it applies to those we like to call “customers.”
Perhaps this is a controversial take, but I believe security runs in opposition to many other quality attributes (i.e., usability, interoperability). Not to say that there aren’t designs that could exist that are optimal for security and these other quality attributes simultaneously, but security massively reduces the potential design space to the point where there is no rule that at least one of these optimal designs must exist.
Quality is an opinionated measure of a design, which involves tradeoffs based on your goals, values, etc. Valuing security very high, even at the expense of every other aspect of quality if necessary, is completely understandable. But that’s a value that isn’t universally held.
If your point is that security should at least be considered when measuring quality these days (like, it’s a top 10 ‘ility’ at least): fair enough.
Isn't high quality defined by how easy it is to maintain as the scale grows? I feel there is a disconnect between the "quality as perceived by developers" and the "quality as experienced by designers and users."
Quality is the extent to which the end product meets expectations. Also, quality attributes are well-defined in the ISO 25010 standard so I'd stick to those rather than imagining some for myself.
Absence of problems is definitely a major factor but I like to think of 'maintainability' as being the main marker of quality. Maintainable code has fewer problems because it makes problems easier to solve.
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 stuff about scale not allowing quality resonated with me.
baseless speculation follows!!!
I think large orgs can definitely achieve high quality. but only by spinning up small, totally autonomous teams working on every layer of whatever stack their product is on, one team per product (maybe two if there's some really obvious line in the sand between two different things that talk to each other, but be careful! and make sure both teams are in the same timezone!).
As soon as you start trying to do those things that seem really sensible when you have a bunch of separate autonomous teams - like "hey you're both working on similar features, you should share the implementation", and "oops all our products look different, we should come up with a unified component library", and "we need automated tests - everyone should use this specific tool that we paid for" you run into the big org problem.
My gut feel is that the best way to get some level of coherency without running into these problems is to share knowledge, best practices, examples etc. But never dictate anything that actually gets in the way of any of your teams owning their own shit. Don't make teams use some internal/external library for functionality x, don't enforce processes, don't have a separate design team dictating css styling to teams, don't enforce org wide CI policies, don't have a separate DevOps team handling releases - just hire competent people and let them do their thing. If you do want to try to build something so that all the teams solve the same problem in the same way, you need to get them to use it by making it so good they want to, not by telling them they have to.
You might be able to enforce some baseline level of mediocrity by doing those things, but the only way to achieve excellence is to get out of the way and stop trying to "help".
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.
Agreed. We cant even get 10 dentists to agree which toothpaste to use. Getting 100 experts to agree on anything is a miracle.
> We cant even get 10 dentists to agree which toothpaste to use.
The 1 in 10 who didn’t recommend $PASTECORP made up the 9 in 10 who recommended $NUTRAPASTE
Toothpaste brand/variant, by and large, doesn't matter.
There is over 30 different variants of Colgate Toothpaste, do dentist believe ALL the Colgate ones are better than the alternatives?
Sometimes yes. My dentist explained she recommended Colgate because none of their 30 equal choices used to contain stannous floride, so it was easier to shop by brand than search for which ingredient to avoid specifically amongst the competitors 30 choices
Oh but it does, they just don't give the US access to the good stuff. Sensodyne Repair & Protect with NovaMin is available in Europe, but because American Crapitalism, aka money aka FDA, you can't get it in the US.
Fluoride is good for teeth but not for your gut and the rest of the body
I don't think you're supposed to be eating the toothpaste.
I eat a quarter of a tube of toothpaste per day. Other than the weight loss, hair loss and reduction in bowel control, I have not noticed any negative side effects. Helps keep my insides clean.
Because different toothpaste is helpful for different cases and reasons?
[dead]
Take curl, it has had many more than 100 experts going through it over the years, and yet with new tooling (AI) they located a bunch of other issues. Perfection in software does not exist, but that's fine as long as you're aware.
(in the case of curl, any security issues inside the library should be mitigated by its environment)
Presumably, this is why the next paragraph opens with "Perfection is impossible."
So, if 100 experts can’t find a problem, the thing is probably perfect. Unfortunately, this will never happen, because perfection is impossible.
Top money's worth can play a big part if there is no shoddiness. Does not have to be luxury range at all.
I didn't see this addressed in the article, and it could be more important than some of the main points.
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 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.
OP didn’t say “little-used” software, they said “nobody,” and I think this was meant to be taken literally in this context. Software that has 0 users is of no use to anyone by definition.
If you are using quality as a metric then something having more quality would mean it having more value to more people. So a piece of software working 95% of the time to 1 mil users is deemed "of higher quality" by this metric than a piece of software working 100% of the time to 1k users. I don't think this definition for quality is good at all
You’re still missing the point: software used by LITERALLY 0 PEOPLE cannot be useful. Whether it’s well written is completely irrelevant because it, by definition, is providing value to NOBODY.
Yes, such software exists.
And you're still missing the point that software nobody uses can be of excellent quality.
Agreed. The quality of a software package doesn't change when its last user stops using it. We don't say that the Apollo Guidance Computer software is of low quality these days given that nobody's using it.
Software quality is, roughly speaking, intrinsic to a software product. Its usefulness is not intrinsic, it can depend on any number of external factors. Quality is not the same as usefulness.
But if it’s unused then how does one measure quality? We can write all the tests, look at architecture patterns, etc. but software truly is a case of “the proof of the pudding is in the eating.”
By your logic, IKEA is the highest quality furniture because it's in more homes than for example Herman Miller furniture.
But that’s not my argument at all. I’m saying that quality is impossible to measure if 0 people use it. Once you go above 0, it can be measured and it’s not necessarily related to how many people use it.
It is still possible to measure the quality of software (or other products) simply by defining a metric that proves quality and testing for it
If I were to write 2 simple functions that reverse an array, and one successfully reverses an array and the other just randomizes it - despite never using this function, we could all agree that function 1 is of higher quality than function 2.
This is an extreme example but the same can be done for, lets say, speed or error handling.
While I think the example is too fake as to be too useful, let's take it. While we could read the code and say that one appears to achieve the job we want and the other doesn't; you don't know if the one that apparently does the job actually does the job until you put it into real-world use. You can't know it'll run with acceptable speed, edge-cases, etc. until you actually run the code in production!
If that code never goes into production with real customer use-cases, everything we say about its quality (on any metric) is 100% theoretical! We can try to replicate that environment, and we should, but until it's actually used, we can't truly know.
Yeah I think the absence of problems is one way to think about it but it's closer to half the equation.
Quality is a set of characteristics that are ultimately decided by the user, and not every user will agree on what those characteristics should be. This is why user testing of all sorts is very valuable.
You have to go back to Walter Shewhart's work and writings while at Bell Labs. In 1931's 'Economic Control of Quality of a Manufactured Product' he draws a line between 'a thing' and the human experience of it, drawing heavily from the philosophy of C.I. Lewis:
"There are two common aspects of quality: one of them has to do with the consideration of the quality of a thing as an objective reality independent of the existence of man. The other has to do with what we think, feel or sense as a result of the objective reality. In other words, there is a subjective side of quality."
He draws a line between objective quality (the measurable, physical things) and subjective quality (the human relationship to those properties).
Later in 1939's 'Statistical Method from the Viewpoint of Quality Control' he gives a good example:
"Let us take a very simple example. Suppose we consider the quality of a glass of water. We may list some of its characteristics as follows: temperature, volume, chemical purity, taste, clarity, and color. If we look at any one of these characteristics, say temperature, we see that it is impossible to specify the temperature of a glass of water to the last degree of accuracy."
I would argue this is the standard to go for when looking for a definition. Ask yourself what makes a quality glass of water and you'll immediately realize you need to ask 'according to who?'.
Well said.
The distinction between "measurable objective" vs. "perceptual subjective" is fundamental to understanding quality.
To add to the above; From https://en.wikipedia.org/wiki/Software_quality -
The transcendental perspective deals with the metaphysical aspect of quality. In this view of quality, it is "something toward which we strive as an ideal, but may never implement completely". It can hardly be defined, but is similar to what a federal judge once commented about obscenity: "I know it when I see it".
The user perspective is concerned with the appropriateness of the product for a given context of use. Whereas the transcendental view is ethereal, the user view is more concrete, grounded in the product characteristics that meet user's needs.
The manufacturing perspective represents quality as conformance to requirements. This aspect of quality is stressed by standards such as ISO 9001, which defines quality as "the degree to which a set of inherent characteristics fulfills requirements".
The product perspective implies that quality can be appreciated by measuring the inherent characteristics of the product.
The final perspective of quality is value-based. This perspective recognizes that the different perspectives of quality may have different importance, or value, to various stakeholders.
> circumstances are forgiving enough.
I once saw an organization that migrated from Weblogic to Kubernetes, keeping the rule to have a least two instances of each app but forgetting that that their Weblogic had distributed transactions and without implementing something similar in Kubernetes.
They happily serve users, helped by low traffic and low expectations. Occasional data corruption and race conditions give work to the support maintenance teams.
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
> 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.
> 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.
>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.
Plenty of successful companies that didn't have a great UI, and plenty of failures that did.
...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.
Those CEOs are often not around though once the company has fully matured. Then it’s back to micro managing and endless unclear company priorities..
> too often CEOs adopt designers like a pet
I've even seen a version where the designer is the CEO's daughter, which is the worst possible version of this pattern.
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.
To care enough to recognize it is out of your depth.
Somebody needs to be responsible for quality and say 'no' if not the CEO.
A CEO should know when the people working for them are bullshitting them, blowing smoke...
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.
They hid all 300 functions inside a single hamburger menu, to avoid clutter on my 27 inches screen.
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...).
> It is based on the premise of making work easier for workers. The objective is to thoroughly eliminate waste and shorten lead times to deliver vehicles to customers quickly, at a low cost, and with high quality.
^ = from your linked Toyota Production System philosophy
Thanks for that link! I find those two early sentences to be an insightful and relatively complete loop of process.
When considering using automation or ~A.I. we can easily ask: which part of this loop is our addition improving (or messing up)? Where is the balance that works?
As you point out, answering these what-works/quality questions are not solved problems and expertise is needful, but careful consideration does not seem to be a popular mode in our age of fountaining funny money and magic genies.
I grew up in the '60s where the science fiction/future was always: march of progress and you'll have so much time and choices! Now I am in the future and the reality is close to: who has the time?
More insidiously/invisibly: you have plenty of time for endless momentary thrills, but no one has time to make things better.
Once upon a time there were customer complaint departments and the Production System would get fixed. Then it became suggestion boxes and returns. Then pleading for a Return Merchandise Authorization. Then it's your call is valuable to us recordings before click call hangups. Oops, unhappy customer?--give 'em a coupon to keep up the addiction, it's cheaper than Quality Control.
The latest devolution seems like fire the workers but use AI to mesmerize customers, or just mind control ~investors and ~regulators, since who needs cover-our-costs-paying-customers anyway?
Will the pendulum swing back?
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.
I tend to agree with a few others here, Quality is not just the absence of problems, it is something deeper.
For me it means care and attention were paid while developing, the rough edges have been smoothed off for want of a better phrase. This doesn't mean using the latest and greatest framework or library, usually quality will come from a deep understanding of the basics and concepts like design patterns .
You can spot quality code in the same way to can tell a fake Rolex from a real one but the quality of the movement.
> Quality is impossible at scale
That's a "yes and no" thing. Handmade quality, yes, but some companies get pretty good at finding a "sweet spot," between better-than-average quality, and "Rolls Royce" quality.
Source: I worked for a company that was pretty much renowned for Quality. We made stuff that is pretty near the top shelf, but still a rung or two under the top.
It's not easy.
Also, customers are willing to pay for garbage. As long as that continues, garbage producers will drive quality producers out of business.
"Quality is the absence of problems" is an example of the reification fallacy, because a problem is not a fixed thing. A problem is only a problem because someone decides it is so.
This is why a better definition is "quality is value to some person who matters." This definition instantly places you at the crux of the matter, which is not about a state of the world or of your product in the world, but rather about WHO matters and how they FEEL about your product.
A more rigorous definition of software quality can be found in ISO 25010.
> The quality of a system is the degree to which the system satisfies the stated and implied needs of its various stakeholders, and thus provides value. Those stakeholders' needs (functionality, performance, security, maintainability, etc.) are precisely what is represented in the quality model...
Here is a decent summary: https://iso25000.com/en/iso-25000-standards/iso-25010
Not exactly software quality, but adjacent, is the capability catalog of dora: https://dora.dev/capabilities/
Dora is about 'software delivery and operations performance' and has a vast body of empirical research underpinning it.
Quality software meets its requirements. Both functional and non-functional. Of course our industry still cannot quantify non-functional requirements, or discover a way to predictably implement functional requirements.
So all that remains for our so called “engineering” discipline, is an answer that says something that doesn't break a lot.
“Zen and the art of motorcycle maintenance” is a good read on the topic of Quality.
> 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.
Quality is the ratio of the value you derive from the software to the cost to you of using it.
Most typical quality attributes can be subsumed under this schema.
If the software costs too much to change because the architecture is poor, that reduces the quality.
If the interface is poor or it is slow unnecessarily, it costs you more time to use it, and that reduces its value to you and hence its quality.
If the software is insecure, you may actually lose privacy or even money using it.
If the software is not robust, you run the risk of losing data and time, etc. when using it
I also think of Quality as “usable,” “discoverable,” “pleasant,” and “accessible.” He covers them, in some fashion.
Some of these are difficult to quantify, but are often the difference between success or failure, in the market.
I constantly encounter “dead” software. Software that is correct, performant, awesome (in some cases), but something that I don’t “want” to use. A “necessary evil.”
That kind of statement doesn’t fly well, in a community of “Inspector 34”s, but it applies to those we like to call “customers.”
Strangely "elegance" isn't even mentioned. "Beauty" comes close but is not the same.
And "simplicity" comes to mind. Also not mentioned.
Why no security? It's mid-2026, high quality software must be secure by design or you won't be using it.
Perhaps this is a controversial take, but I believe security runs in opposition to many other quality attributes (i.e., usability, interoperability). Not to say that there aren’t designs that could exist that are optimal for security and these other quality attributes simultaneously, but security massively reduces the potential design space to the point where there is no rule that at least one of these optimal designs must exist.
Quality is an opinionated measure of a design, which involves tradeoffs based on your goals, values, etc. Valuing security very high, even at the expense of every other aspect of quality if necessary, is completely understandable. But that’s a value that isn’t universally held.
If your point is that security should at least be considered when measuring quality these days (like, it’s a top 10 ‘ility’ at least): fair enough.
Isn't high quality defined by how easy it is to maintain as the scale grows? I feel there is a disconnect between the "quality as perceived by developers" and the "quality as experienced by designers and users."
Quality is the extent to which the end product meets expectations. Also, quality attributes are well-defined in the ISO 25010 standard so I'd stick to those rather than imagining some for myself.
Absence of problems is definitely a major factor but I like to think of 'maintainability' as being the main marker of quality. Maintainable code has fewer problems because it makes problems easier to solve.
> 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?
Quality is an opinion based on your perspective. The author articulates quality from their perspective, which has value, but isn’t universal.
We should look at the nature to learn what quality means. Survive first with whatever it takes. Then if you have comeptition, keep improving.
> Beauty: Is the software as aesthetically pleasing as possible?
Imo this point should be changed to reviewability. Beauty is in the eye of the beholder
Since it’s so subjective let’s poll our engineers’ NPS!
“How likely are you to work in this codebase again?”
0 = Least likely 10 = Most likely
(Anthony has some great paper solo role playing games on his blog too)
What a beautiful website.
[flagged]
[flagged]
[dead]
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 stuff about scale not allowing quality resonated with me.
baseless speculation follows!!!
I think large orgs can definitely achieve high quality. but only by spinning up small, totally autonomous teams working on every layer of whatever stack their product is on, one team per product (maybe two if there's some really obvious line in the sand between two different things that talk to each other, but be careful! and make sure both teams are in the same timezone!).
As soon as you start trying to do those things that seem really sensible when you have a bunch of separate autonomous teams - like "hey you're both working on similar features, you should share the implementation", and "oops all our products look different, we should come up with a unified component library", and "we need automated tests - everyone should use this specific tool that we paid for" you run into the big org problem.
My gut feel is that the best way to get some level of coherency without running into these problems is to share knowledge, best practices, examples etc. But never dictate anything that actually gets in the way of any of your teams owning their own shit. Don't make teams use some internal/external library for functionality x, don't enforce processes, don't have a separate design team dictating css styling to teams, don't enforce org wide CI policies, don't have a separate DevOps team handling releases - just hire competent people and let them do their thing. If you do want to try to build something so that all the teams solve the same problem in the same way, you need to get them to use it by making it so good they want to, not by telling them they have to.
You might be able to enforce some baseline level of mediocrity by doing those things, but the only way to achieve excellence is to get out of the way and stop trying to "help".