[betenoire]

I agree, and take it a little further. 10 engineers couldn't agree on the _point_ of quality code to begin with, let alone define how to get there. Consider two programs:

1. The spaghetti mess, half-done abstractions, inconsistent uses of anything everwhere. But accomplishes the users expectations perfectly 2. A beautiful codebase, clean abstractions, tests and documentation everywhere. But the user hates it. It's slow, requires some domain knowledge of how to drive and get result.

Two very contrived examples, but not unrealistic examples.

Intuitively, better cabinet quality leads to a better cabinet experience. Does better code quality lead to a better product? It should, that's what quality is about. And if not, is "quality" even the right word?

Whenever I hear an engineer talk about quality, I clarify. What kinda of quality are we talking about?

[ffitch]

good point. perhaps code quality and product quality are different things.

[betenoire]

Right, and they are, that's my point. Quality isn't a single attribute of a system, it's a judgement call based on objectives.

The objectives of a business selling software, and that of engineers is something else. Sometimes maintenance, sometimes extensibility, sometimes exploration, sometimes just seeing if something is possible. Quality correlates to the objective, and in my experience, many software engineers have a hard time seeing their code through other perspectives.

[farley13]

There is a lot to be said for getting outside the four walls of a business (or org) to evaluate things. If it's not visible outside those walls (software buggy enough to lose customers) and doesn't introduce significant future risk to the business (competition can move faster than you) it's probably good enough. The real trick of course is predicting and communicating why you think one of these is true. It's an essential problem of commercial software dev.