Using production metrics as a whole is very stupid and a good way to get devs to optimize for the metrics rather than quality work. A contemporary example would be a company that promotes for "impact" (i.e. launching new products) which is a great way to have a bunch of failed products that nobody maintains!

The trick is to align the metrics with company goals. It's not easy, but not impossible either.

For example, if quality is your goal, then the metric you give your devs is "number and severity of bug reports coming in from customers". If unsatisfied feature requests are part of that number, then the devs have to strike a balance between churning out features and preventing bugs (and fixing discovered ones).

Obviously your customer support needs a different metric.

Ye and you end up with blame games and hot potatoes being passed around.

Bug count metrics incentives "don't touch anything" and coding with feuture flags and globals to limit the scope of change and circumvent the architecture.

Like, just don't do metrics and have the management actually review the work of their subordinates if that is important to follow up on. Actual management can't be compressed to a acting on some scalar values.

Objective measures are a good thing. Otherwise you just end up with some subjective opinions nitting bro culture even closer together.

I know at least a few many-hundred-billion dollar companies that fit that description...

I’m sure there are engineers who fix a critical bug every few months and generate millions of dollars of value, but as a general rule great engineers tend to be prolific and engineers who aren’t prolific tend to not be great.

Engineers who are obsessed with greatness tend to not be great either

In my opinion, there is still some relation between LoC and engineering output over a long period of time. Some of the greatest computer scientists and engineers have insane code outputs and I believe it does directly translate into impact in some ways. The issue is when Loc becomes a metric to measure performance. At that point, we have an instance of Goodhart's Law: “When a measure becomes a target, it ceases to be a good measure.”.

As your examples indicate, one reason it's a bad production metric is that it's a reasonable measure of the burden carried by the maintainers of the codebase. The production metric point of view classifies code as an asset. It's closer to the truth to view the functionality as an asset, and the code itself as a liability.