What Is Software Quality?

Last time, we talked about what is Clean Code. Now it’s time to talk about quality.

Quality is a strange thing. We all want it. We all claim to recognize it. But when we try to define it, the conversation often gets... fuzzy.

There’s a quote in Zen and the Art of Motorcycle Maintenance that captures the dilemma perfectly:

"Quality... you know what it is, yet you don’t know what it is. But that’s self-contradictory. But some things are better than others, that is, they have more quality. But when you try to say what the quality is... it all goes poof!"

So let’s start with that:

Quality is hard to define, but easy to recognize.

Quality as a Feeling

Think of quality like walking into a well-designed room.

You might not be an architect or an interior designer. You might not be able to articulate the color theory, material choices, or layout techniques.
But you know when the room feels good.

And you also know when it doesn’t—when the lighting is off, the layout is awkward, or the furniture makes no sense.

Software is no different. You can feel when a system is thoughtful, robust, and responsive—even if you can't immediately list why.

Does “Software Quality” Even Mean Anything?

The term software quality gets thrown around a lot—by developers, managers, consultants, and vendors alike. It sounds good. Who wouldn't want “high quality” software?

But dig a little deeper, and you’ll find that everyone seems to mean something different by it. For some, it’s about performance. For others, it’s about reliability, security, design, or customer satisfaction. In meetings, “quality” can mean whatever supports the current argument.

This vagueness can be misleading.

In his essay The Aura of Software Quality, Derek Jones argues that the term might be more about perception than substance:

“People in industry are very interested in software quality, and sometimes they have the confusing experience of talking to me about it. My first response, on being asked about software quality, is to ask what the questioner means by software quality. After letting them fumble around for 10 seconds or so, trying to articulate an answer, I offer several possibilities (which they are often not happy with). Then I explain how ‘software quality’ is a meaningless marketing term. This leaves them confused and unhappy. People have a yearning for software quality which makes them easy prey for the snake-oil salesmen.”

It’s a provocative view—but not entirely wrong.

"Software quality" is broad enough to mean everything, and vague enough to mean nothing. That ambiguity makes it easy to misuse. Entire industries exist to sell the appearance of quality—tools, processes, certifications—without clearly defining what they actually improve.

That doesn’t mean we should abandon the concept altogether. But it does mean we need to be more precise:

• What kind of quality are we talking about?

• Who defines it?

• Under what context?

Until we answer those questions, conversations about software quality risk being more about comfort than clarity.

Two Kinds of Quality

In Zen and the Art of Motorcycle Maintenance - which isn’t a software book - author Robert Pirsig describes two fundamentally different perspectives on quality:

Classical Quality

This is the analytical view of quality. It’s about the internal mechanics, structure, and design of a system. In software, this might include things like:

• How well components are modularized

• Whether the architecture scales

• Test coverage and static analysis results

• Code maintainability, reliability, and technical precision

This is how engineers often approach quality: Does it work? Is it robust? Is it built well?

Romantic Quality

This is the experiential view. It’s about how something feels when used, how it fits into someone’s life, and how much joy or frustration it delivers. In software terms, this could include:

• How intuitive the interface is

• Whether it “just works” out of the box

• Aesthetics, branding, and user delight

• Emotional trust and user satisfaction

This is how users experience quality: Is it usable? Does it make sense? Do I enjoy using it?

The Tension — and the Truth

These perspectives often pull in different directions. You can have a beautifully engineered system that’s painful to use. Or a clean interface hiding a brittle, chaotic backend.

True quality balances both views. That’s where great software lives: in the intersection of clean internals and good user experience.

So... What Is Software Quality?

With so many possible angles, it’s no wonder the definition of software quality varies depending on who you ask—and what they care about.

Here are just a few definitions in the wild:

• ISO: Defines software quality as the capability of a software product to conform to requirements. This is a very classical, specification-driven view—focused on correctness, precision, and verification.

• ASQ (American Society for Quality): Breaks software quality down into two approaches:

  • Defect management – minimizing bugs and failures

  • Quality attributes – ensuring desirable properties like usability, performance, and maintainability

• Tom DeMarco: Offers a more human-centered take:

“A product’s quality is a function of how much it changes the world for the better.”

Some definitions focus on internal correctness. Others on external value. Some are about measurable properties; others about emotional or societal impact.

There’s no single definition that fits all situations—and that’s okay. The important thing is to be clear about which kind of quality you’re aiming for.

The Four Pillars of Structural Quality (CISQ)

Personally, when I think about software quality as an engineer, I often lean toward the classical side. And one framework I’ve found especially useful comes from the Consortium for Information & Software Quality (CISQ).

They define four pillars of structural quality—essentially, the internal health of a system:

1. Security

Can your system defend itself against threats?

• Input validation

• Safe handling of credentials and user data

• Secure defaults and hardened architecture

2. Reliability

Does the system behave predictably under stress?

• Uptime and availability

• Graceful failure modes

• Robustness under load

3. Maintainability

Can the system evolve and adapt over time?

• Code clarity and modularity

• Manageable technical debt

• Test coverage and automation

4. Performance Efficiency

Is the system making good use of its resources?

• Response time and latency

• CPU/memory usage

• Scalability under real-world conditions

These pillars don’t cover everything—but they’re a solid foundation for evaluating and improving the technical quality of a system, especially at scale.

They’re also a way to bring the idea of quality out of the abstract and into actionable engineering goals.

Wrapping Up

Software quality is hard to define because it’s not just one thing. Sometimes it’s about clean architecture, sometimes it’s about how the product feels to users, and sometimes it’s just a buzzword used to sell tools and processes.

But even if we can’t agree on a single definition, we can still be more intentional: What kind of quality? For whom? And why does it matter here?

Next time, we’ll dig into a question that naturally follows: Is clean code part of software quality—or just a nice-to-have? Let’s find out.