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