I've tried many times. It usually comes down to this: "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?"
Unless they wrote code in the last few years - I don't see people ever relating. It's just some abstract problem to them and you never get enough time to thoroughly explain how it all works.
Unfortunately, we're not like a factory. You can't make the retooling argument in the same way and see blatantly obvious results. It's more nebulous.
If someone out there figures it out - I'm sure we'd never have these discussions. They'd say, "Oh, why don't you just use the bradlys argument? He wrote it up on HN some years back and this refactoring discussion has been solved ever since."
> "I don't get it. We've managed for so long to do things quickly - why is it now that we can't go fast?"
"You can go fast when you're rapidly prototyping something that doesn't have to go to production, doesn't have to support thousands of users, is allowed to fall over at any time, and doesn't need to be maintained. You can also go fast when you're working on a well-designed system that is designed to support what you're trying to do. But the moment you start making it do something it wasn't originally designed to do, you slow down, and you risk turning the code into a mess that will slow you down even further in the future. If you want to go fast, let us refactor it now, so it will support the things we want to use it for."
And if they don't get that, maybe they shouldn't be in a position to make decisions about this sort of thing. Though I guess they won't respond well to you telling them that.
Many managers should indeed not be in the position to make decisions about these sort of things. Yet they are.
As you mention, they don't respond well to telling them that. Their own managers also don't like the implication that they made a mistake in whom to promote. Since everyone wants to protect their own career, nobody will ever step down or revert such a decision, with predictable results for overall product quality.
Unless they wrote code in the last few years - I don't see people ever relating. It's just some abstract problem to them and you never get enough time to thoroughly explain how it all works.
Unfortunately, we're not like a factory. You can't make the retooling argument in the same way and see blatantly obvious results. It's more nebulous.
If someone out there figures it out - I'm sure we'd never have these discussions. They'd say, "Oh, why don't you just use the bradlys argument? He wrote it up on HN some years back and this refactoring discussion has been solved ever since."