From the Spencer paper:

"In such cases,it is important to go back and fix the kludges. The time is
not wasted; it is an investment in the future"

Yeah, well, that's the problem, isn't it?  Investment in the future is not
incentivized.  The manager needs a win *now* so he can collect his bonus
and then leave for someplace that will pay him more.  Even as a lowly
engineer I've never seen a place where it made financial sense to stick
around.  You'd never get compensation, authority, and responsibility as
fast by being internally promoted as by hopping to the competition across
town.

If the goal were building a sustainable and maintainable ecosystem, then,
sure.  But it isn't.  Good software engineering doesn't pay.  Barfing out a
checklist of feature bullet points that marketing wants pays.

That does suggest that there's some scope for doing this properly in big
Open Source projects--except those, in reality, are almost always driven by
a very few large funders, who have particular features they want and are
willing to pay for.  Shipping those features then becomes the priority, not
keeping the codebase manageable.

I guess it comes down to "hate the game, not the player" on my part and I'm
having a grumpy day.

Adam