A father of these being, as usual Dijkstra: in his EWD1036-28 "On the cruelty of really teaching computing science" (1988-12-02) he notes
> it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
(emphasis mine)
Though of course "lines of code" in Dijkstra's essay is itself only a proxy, a line of Java code and a line of Perl code have fairly difference costs.
I do not think a product with zero lines of code is always better than a product with 10,000. So there is obviously some metric that goes up with lines of code but goes down with bugs and technical debt.
Sometimes the downswing from a single line is so dramatic, that such maxims are expressed... but don't take them too literally. Let's be real here.
Which is why Dijkstra's take on it is excellent: the LOCs you write are a liability. Incurring liabilities is normal, but your goal isn't to maximise liabilities.
That might be a good way for engineers to think of it, but you don't really want managers to see programming as a liability, because then they start thinking in terms of eliminating liability for business productivity (i.e. killing your job, not investing money to let you do your job effectively, etc).
There's already enough problems with companies considering their tech departments to be "cost centers" that don't result in direct revenue generation, therefore they don't respect the department enough, we don't need them thinking we're completely undesirable.
But it is a liability. If your business could generate the same revenue while spending less resources maintaining internal technology, you'd do it in a heartbeat.
I don't really get what this "cost center" thing gets you at all. Suppose you make televisions. R&D is a "cost center". Whoever's in charge of sourcing components is a "cost center". Hell, making the damn TVs is a "cost center". In fact, the only thing I can think of that isn't a "cost center" is sales. But without everything else, sales would have nothing to sell.
So what the heck is the point of labelling things "cost centers"?
In the same way, spending $0 is not always a better choice than spending $10,000. You're spending the lines of code with the hope that your return on investment makes the liability worth it.
Think of lines of code as surgery to excise a tumor.
Of course you want to remove the tumor. Curing cancer is the goal. But each surgery is a liability; each scalpel cut you make may bring potentially fatal complications, so you strive to perform as few surgeries as possible while still saving the patient.
Rewarding LOCs is like rewarding the high number of surgeries a doctor had to perform on a patient in order to save him/her. It's backwards!
> it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
(emphasis mine)
Though of course "lines of code" in Dijkstra's essay is itself only a proxy, a line of Java code and a line of Perl code have fairly difference costs.