Generally when you explain to people what you want to do but also agree to do what they've asked for they're relatively happy with the trade-off. My experience

Generally when you explain to people what you want to do but also agree to do what they've asked for they're relatively happy with the trade-off. My experience is that people aren't against things being done properly, it's only an issue when that gets in the way of what the feel really needs to happen. If you come up against people who really just won't listen I tend to make a note of the fix, log it as a bug and include it in the next round of bug fixing, the next bit of quiet time or whatever. Alternatively include the refactoring into the estimate the next time I'd have to do significant work on that module. Two other points while I'm rambling: Always make sure that the refactoring is genuinely necessary and not just polishing. Some developers like "perfect" solutions but often this results in over engineering and significantly increased timescales. The key question I find useful is "am I coding for a specifically stated requirement or probable edge case or am I extrapolating to what I think might be useful / needed in the future?". I'm with Kent Beck on code only for what you specifically need today. Secondly, only real issue with this approach I've outlined is if someone micromanages your time so heavily that you can't do any of that AND they won't listen to reason. In that instance you might want to consider your options but I've only ever once been in that position.