Technical debt or tumour?

I've found that technical debt is not a good enough metaphor for when you do it quick instead of doing it right.

Telling management that when you do it quick you will incur in debt that has to be paid later helps them understand the problem but I think the problem is much worse than just incurring debt.

Because, for me, incurring debt means that later on paying it with some interest you can get away with it. And I think that this interest is localised to the bit that we just rushed in.

This might be the case if the rushed area is isolated and its interface is well designed. But how often is this the case?

I think most people agree with the "broken window" effect. An already broken/neglected code base tend to degrade faster then one which isn't.

If we consider that a technical debt is a "broken window", we can see that it might behave more like a tumour. Areas that need the broken bit now need to adapt to it, which will possibly increase the debt, which might complicate other areas that depend on the just affected area and so on... spreading like a tumour...

On top of this, even areas that are not directly related to the broken bit might start neglected because of the broken window effect.

So, if the area is removed fast enough (the debt is payed in a timely manner), you're safe, otherwise you're dead because your technical debt might have already leaked into too many places and soon people will start talking about the big rewrite...