Your code is a diaper. No no, don't be offended. Have you ever smelled a diaper fresh out of the box? They smell good. They're really white and clean with a touch of pleasant scent added to them. Diapers are actually nice.
Then once you start to use the diaper, smell cometh. Well...you aren't using a diaper, a baby is. er... Anyway what I'm saying here is, you create some nice clean code, then as the code gets added to and moved around, you start to see "code smells", so then things get painful. It's harder to navigate the code, harder to follow what it does, harder to change the code and isolate changes. Pain drives refactoring. That's a good thing. That's a normal thing. Time to change the diaper! So you change the stinky diaper, and then you have nice clean code again. Now you can make changes faster, joyfully, and with fewer errors.
But then there's a paradox. While pain drives refactoring, deadlines postpone refactoring until after the pain. You've been there, right? The code is smelly, but you must have these five features done this week, so you don't have time to refactor, so you get those features done, ship it, then you're on to the next feature, which may not deal with the code you were hurting from. No pain no gain: now that you don't feel the pain, and have other tasks on your plate, you don't refactor that code.
So then instead of this stinky diaper getting changed, the baby is passed on to the next feature during which it gets even stinkier, then the next, then stinkier, next, stinkier, stinkier. Then the poor baby gets a bad rash! ...though I'm not sure where the rash fits in.
So it's a poopy paradox indeed. The solution: have enough time or resources to include regular refactoring as part of the development process. That comes in the planning stage, so if you messed up this time, you'll have to hang onto it for the next planning stage. Include it in your estimates, along with the coding, test-writing, and bug squashing. Don't let the paradox catch up to you. Makes me gag just thinking about it.