[tkiolp4]

I don’t know. If I have learned something in the last decade about software engineering and quality is: business only care about revenue and speed, while engineers don’t have an objective way to define quality (10 engineers would give you 10 different opinions about the same piece of code).

The only moment I consider quality as the top priority is when I work on side projects (because there’s only one opinion about what quality means, because there’s no time pressure and because no one is asking me “are we profitable now?”)

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

[theonething]

> 10 engineers would give you 10 different opinions about the same piece of code

This plays out in code review in a way that drives me insane. So much back and forth and time spent/wasted because there's always that one person or small group of people who insist their way is the one true one.

[bcrosby95]

> 10 engineers would give you 10 different opinions about the same piece of code

It's kinda like ice cream. You can argue if you prefer vanilla or chocolate, but everyone will agree when they're eating shit.

Now business takes this and runs with it: you can't even agree on if vanilla is better than chocolate, so go eat this pile of shit.

[drewcoo]

Trying to get 10 people to agree which is the best chocolate ice cream is closer to the quality problem.

I appreciate the scatological approach, though. And most of the time when I hear the word "quality," it's said in anger that could easily be communicated by flinging poo . . .

[datadrivenangel]

You can't even agree on if vanilla is better than chocolate, so go find a way to let us sell this pile of shit to customers!

[pictur]

Different ideas are of course important. But companies that take every idea seriously usually have as many ridiculous problems as there are ideas. So not every idea may be really good. Accepting this liberates a person.