Let's take bad or short-sighted refactoring off the table and only consider good refactoring. Even in that case it's not obvious when refactoring is justifiabl

Let's take bad or short-sighted refactoring off the table and only consider good refactoring. Even in that case it's not obvious when refactoring is justifiable. If it's just one or two small features hacked onto a sub-optimal code base then probably not worth refactoring, but what if it's more? Well, you might want to actually build them first and then refactor once you have good test coverage and proven use cases. But wait, what if the old architecture is forcing a lot of incidental complexity that will be costly to unwind? In that case it may be better to pay the refactoring cost up front. The point is that any engineer who is always refactoring or never refactoring is doing it wrong. All cases require judgement of the specific situation and balancing short-term goals with long-term vision.