Code quality also exists on different axes. I've seen the case where code quality was poor in some aspects, e.g., tons of technical debt, coupling making it difficult to make changes, but overall product quality was very high. It had to be: it was a medical device.

Most environments only care about the output. In the case I'm thinking of, Software made it perfectly clear to Management, most of whom were former engineers, that the product desperately needed redesign in some ways. But as long as the cost of that redesign exceeded the cost to get the next version out, it could be postponed. This went on for years.

Code quality directly correlates to everything you describe.

As code quality goes down, so does productivity, as it becomes more difficult to add new features and there are more bugs introduced.

Nobody cares until the code gets so twisted in knots that bugs and security issues predominate.

I think some tests should be considered to be part of the specification rather than the product.

As one that does, it’s a difficult discussion to have with the executives. My peers look like their teams are producing more than my teams are and any argument along the lines of “but their code sucks” isn’t going to hold water. The executives care but until there’s actual impact or poor quality, it won’t matter, and it’s a lagging metric. Many still don’t care about technical debt and that’s been well understood in industry for a while.

It’ll take production incidents, impacted customers, and brand damage to make the executives start to prioritize quality over quantity again.