I just stumbled across this very true summary about technical debt and how to deal with it:

http://www.nomachetejuggling.com/2011/07/22/when-to-work-on-technical-debt

In my experience technical debt always happens. One must always try to avoid it but it can never totally be avoided (for multiple reasons). The main point is: You (the one who writes and maintains the code) must deal with it in your daily normal work every day immediately and you must organize to pay it off without asking for permission or telling other people.

The sentence 'We never have enough time to pay off our technical debt' does not make sense and is wrong. Nobody will provide you with time to do this and nobody will schedule it for the future. You need to deal with it yourself. You need to factor any cleanup into the planning. Do not expect extra time to be given to you to clean up later.

The sentence 'This is so wrong, we should fix it. Let's add this to our defect database so it does not get lost.' usually means: 'I don't understand or care about technical debt so let's put this into a strange ever growing database and forget about it. It will never get done.

Defect databases most of the time help to create technical debt since they encourage people to file work items which really need to be done now for the future. They do not help to reduce technical debt. A 8x8cm piece of paper with the top issues on it you need to work on is better. You usually will not be able to deal with more debt than what fits on this piece of paper.

I always compare technical debt with a snow-pusher which has a flat pushing front. By pushing harder it can always get a bit further by pulling back and by ramming into the snow wall once more, but after some time it can only ever advance by a couple of centimeters per push. The only way is to get rid of the snow is to get rid of the snow. Pushing the snow forward for future processing is not going to work.