I do think that, in my experience, most organizations don't think the amount of code they already have written, is a thing they need to minimize or even track. Yet, most organizations are limited in their ability to develop, by the amount of already existing code that has to be understood and maintained. The usual attitude seems to be that "it's already written, we don't have to pay anything more for that". The idea that existing code, the sheer quantity of it, is a drag on an organization's ability to write new code, was not clearly understood in any place I've ever worked.
Would you say that the larger the organization, or perhaps more accurately, the further a developer is separated from "owning" their code, the worse this issue is?
In my case, if my code causes a bug, I have a very few steps between the person reporting the bug and the complaint getting to me. It feels personal.
Your suggestion seems to imply it's just money, but how do bean counters effect ground level code decisions in an organization?
I think that, it's not money per se, but as you say the number of people between the developer and the decision maker. The only person who perceives the problem of having too much code, is the developer (and then only sometimes). Organizations do well at optimizing what they track, in many cases, but they don't track amount of existing code as a negative thing that needs maintaining, so they don't do well at optimizing that.
