If you can get 100 experts to agree on something then you've cracked a much harder problem than software quality.

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

I'm interested in quality, but I didn't find these notes enlightening, and couldn't even finish the article.

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.

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

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

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.

So all that remains for our so called “engineering” discipline, is an answer that says something that doesn't break a lot.

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

And "simplicity" comes to mind. Also not mentioned.

The what? Since when has "the industry" been able to define best-designed, much less agree on it?

Imo this point should be changed to reviewability. Beauty is in the eye of the beholder

“How likely are you to work in this codebase again?”

0 = Least likely 10 = Most likely

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

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.

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.

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