Sometimes we write code or a test and think: make it work first and refactor it later. But this ‘later’ may not come in a while.
What would you say about a mechanic or a craftsman who makes his work and does not clean up afterwards? Would you drive your car with stuff lying in the engine bay? Or use your bath with dirt all over?
Certainly not.
So don’t wait until someone cleans your code or until you come back after a while and the first thing you do is cleaning up.
I know that when things get tough, deadlines are near, refactoring does not have top priority. So why not use an iteration or even some hours to clean up afterwards? It will help you in the future.
Refactor now
What would you say about a mechanic or a craftsman who makes his work and does not clean up afterwards? Would you drive your car with stuff lying in the engine bay? Or use your bath with dirt all over?
Schneide Blog 
I disagree here. Imho it is not about refactoring immediately and commit only perfectly clean code but about “refactoring on-time”. I tend to leave my code in a shape where it is easily refactored. If someone comes along *he* has to refactor it into shape *before* adding features or the like.
If that refactoring does not happen such code easily grows into a hard to refactor mess. So refactor the code when you need it, e.g. when you need to add a feature or fix a bug.
Well, I think perfectly clean code is almost impossible in a non trivial code base. So you have to stop somewhere, that’s right. But leaving a mess so that the next guy has to shave some yaks before he can do his work is a disservice to him. Don’t get me wrong here: gold plating is not the goal. So you have to make a cut in between. Where that cut is is your and your teams’ responsibility. As always use your common sense.
“On-time” does *not* mean “leaving a mess so that the next guy has to shave some yaks”. That was exactly my point: Leave the code so that it is easy to work with. Neither more nor less!