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.

▲

quietkoala 4 hours ago | parent | next [-]

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 4 hours ago \| parent [-]
		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.

▲

jerf 4 hours ago | parent | prev | next [-]

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.

	▲	amarant 3 hours ago \| parent [-]
		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

▲

chasd00 4 hours ago | parent | prev | next [-]

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

	▲	4 hours ago \| parent [-]
		[deleted]

▲

MaxBarraclough 4 hours ago | parent | prev [-]

> 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 4 hours ago \| parent [-]
		I think readability is very important for quality. It creates resilience against any hardship that requires changing the code, which is probably most hardships.