said, "This is an economic judgment. Several times, many times, I run into teams that say something like, “Oh well. Management isn’t allowing us to do a quality job here because it will slow us down. And we’ve appealed to management and said we need to put more quality in the code, but they’ve said no, we need to go faster instead.” And my comment to that is well, as soon as you’re framing it in terms of code quality versus speed, you’ve lost. Because the whole point of refactoring is to go faster.
And this is why I quite like playing a bit more with the metaphor as the health of a codebase. If you keep yourself healthy then you’ll be able to run faster. But if you just say, “Well, I want to run a lot so I’m therefore going to run a whole load all the time and not eat properly and not pay attention about this shooting pain going up my leg,” then you’re not going to be able to run quickly very long. You have to pay attention to your health. And same with the codebase. You have to continuously say, “How do we keep it in a healthy state? Then we can go fast,” because we’re running marathons here with codebases. And if we neglect that internal quality of the codebase, it hits you surprisingly fast."