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

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

In my experience technical depth 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 software) 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 depth' 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 without any additional time.

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 depth 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 depth 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 depth. A 8x8cm piece of paper with the top issues on it you need to work is better. You usually will not be able to deal with more depth than what fits on this piece of paper.

I always compare technical depth with a snow-pusher which has a flat pushing front and by pushing harder 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.