[taeric]

I still think the whole metaphor of technical debt is borderline worthless. Taken to its extreme the simple act of using programming language is akin to taking a loan against the expertise of other workers.

That is, "technical debt" should be regarded as normal debt, if the metaphor is to be worth anything. As such, so long as you are making more progress due to the debt than you would in paying it back, it is probably wise to keep it.

Consider, nobody would say you should put every dime you own into paying off a mortgage. How would you eat? Now, they will say to be wise and pay attention to the amount of debt you take on.

But realize the main problem with this is looking at personal/consumer debt as at all analogous to business debt. They are not as comparable as basic intuition would lead you to believe.

[AndrewKemendo]

It is debt though, because as I understand technical debt, it is something that needs to be fixed on a fairly short timeline (6-18 mos) without breaking some major process.

As such, so long as you are making more progress due to the debt than you would in paying it back, it is probably wise to keep it.

I think this makes sense too, because you can fix hacked code as you go to "pay down" technical debt.

[taeric]

Right, but now the metaphor is so malleable as to be worthless. It is almost literally "you should pay down debt, except when you shouldn't." With very little literature talking about the later.

Seriously, the rhetoric in use is "Living with technical debt is like living with a hole in your roof - you clean up the rain water the first couple times but in the long run you want to fix the damn hole." That isn't living with technical debt. That is living in a bloody broken home.

Instead, living with technical debt is living in a home where you still have low efficiency windows. Driving a gasoline car. Not having the latest heat exchange technology. Having AC pumped into a house that is now nothing but converters to DC.

Sure, in the future things will look different. Odds are high that it makes zero sense for you to force these changes today.

[AndrewKemendo]

Eh, I don't know if one or the other is necessarily correct, I think it is a spectrum and depends on an individual project's situation.

So for one company tech debt is something that will cripple them next week and for another it is something that they can manage over a long period; that still matches how we discuss financial debt so I see no conflict.

[taeric]

I think my problem comes down to my point about living in a broken home. If you have broken windows, fix them. If you just have windows you don't like, do a cost/benefit on replacing them.

And realize that, piecemeal replacing things may not be a good idea. Running with the window analogy, if all you did was replace one window. Sure, in some way you are better than if you had not replaced it. Odds are high it will actually hurt your valuation on the home if it doesn't match the look of the other windows, though.

Same for the car analogy. Driving a low MPG car is ultimately expensive. Unless you have done a cost benefit to getting a high MPG one, it is likely not a good idea to upgrade.

This is especially true for most nonsense articles on paying technical debt. They almost always involve becoming an early adopter of a technology. Something which is known to be expensive elsewhere. Consider, the number of folks that saved money by buying a first model or so prius is probably zero.

At work, this is especially poignant. The folks that were most into paying down technical debt have managed to land us with no fewer than 4 dependency frameworks. Sure, I hate struts as much as the next person, I would welcome that to the frankenstein we have wound up with.