Yes, but presumably we all work at businesses that are trying to make money. Code quality and product quality are inextricably linked in the business world.
This is not true in practice because the consequences of bad code show up months and years later and in a way that makes it impossible to attribute to any one business decision.
This is totally fair and I agree with that. What I was trying to say and didn't express particularly eloquently is that you need to consider both "abstract" measures of code quality (performance, test coverage, complexity, rate of regressions/defects, etc.) and specific product metrics. You can deliver "high quality code" that checks off all the abstract metrics, but if it doesn't actually solve your business problem then you've basically just succumbed to Goodhart's Law.
> then you've basically just succumbed to Goodhart's Law
We're talking about adding more metrics that should be considered, and treating or not treating them as the ultimate goal is orthogonal to choosing the set of metrics! Product metrics don't save from goodharting
