6 ms·

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

by amarant 2mo ago

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.

sam_lowry_ 2mo ago
> 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.
speak_plainly 2mo ago
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?'.
- rramadass 2mo ago
  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 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.
quietkoala 2mo ago
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
- MaxBarraclough 2mo ago
  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.
  - deleted 2mo ago
    [deleted]
  - scott_w 2mo ago
    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.
    - ____mr____ 2mo ago
      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
      - scott_w 2mo ago
        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.
MaxBarraclough 2mo ago
> 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.
- amarant 2mo ago
  I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.
chasd00 2mo ago
> 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 ;)
- deleted 2mo ago
  [deleted]
jerf 2mo ago
I think part of what you're reaching for is the concept of anti-fragility: https://en.wikipedia.org/wiki/Antifragility 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.
- amarant 2mo ago
  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

by amarant 2mo ago

sam_lowry_ 2mo ago

> 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.

speak_plainly 2mo ago

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?'.

rramadass 2mo ago
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 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.

quietkoala 2mo ago

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

MaxBarraclough 2mo ago
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.
- deleted 2mo ago
  [deleted]
- scott_w 2mo ago
  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.
  - ____mr____ 2mo ago
    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
    - scott_w 2mo ago
      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.

MaxBarraclough 2mo ago

> 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.

amarant 2mo ago
I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.

chasd00 2mo ago

> 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 ;)

deleted 2mo ago
[deleted]

jerf 2mo ago

I think part of what you're reaching for is the concept of anti-fragility: https://en.wikipedia.org/wiki/Antifragility 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.

amarant 2mo ago
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