Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Notes on Software Quality

anthonyhobday.com

Post reply on HN
Print view View original

21–30 of 82 posts

Re: Notes on Software Quality

#21

Post by MaxBarraclough »

quietkoala wrote: post #18
amarant wrote: post #17

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 defin…

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, i…

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.

Re: Notes on Software Quality

#23

Post by jerf »

amarant wrote: post #17

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 defin…

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.

Re: Notes on Software Quality

#24

Post by [deleted] »

chasd00 wrote: post #20
amarant wrote: post #17

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 defin…

> 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, meeti…

[deleted]

Re: Notes on Software Quality

#25

Post by onion2k »

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.

Re: Notes on Software Quality

#26

Post by amarant »

MaxBarraclough wrote: post #19
amarant wrote: post #17

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 defin…

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

Re: Notes on Software Quality

#27

Post by amarant »

jerf wrote: post #23
amarant wrote: post #17

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 defin…

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

Re: Notes on Software Quality

#29

Post by ChrisMarshallNY »

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

Re: Notes on Software Quality

#30

Post by doginasuit »

jonathanlydall wrote: post #3
manoDev wrote: post #2

> 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 microma…

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.
Post reply on HN