I've always wondered why, in a company that loves 6 sigma and other process improvements, we never really got behind refactoring code. I mean, cleaning the flow of books and nuts through the line is praised, but the flow of an array through logic is not. I think it has to do with the former being easily seen - physical and the latter being abstract. It could also have to do with easily proving repeatability... It is easy to see that the bolts will be installed 500 time in a week; less so about the logic. In fact, I think if we could show measurable velocity improvements from refactored code; it would show business how investing in refactoring pays off. Kinds like a Toyota production system for c++.
I'm agreeing with you. It has to do with code not being visible to management. That is intentional, management doesn't want to see or think about code. They want to push that entire concern to the technical team and never see it. Which is reasonable enough.
Then they have a time demand or feature demands (which amount to the same thing) and suddenly the technical team doesn't see a lot of breathing space to work on code quality. If management trusts a credible view expressed by the technical team or the technical team can irrefutably prove that the added time will improve some metric of business interest then this can change.
