[CoffeeDregs]

Technical debt is like credit card debt: it's high interest; it's not a huge issue if you use it wisely; and you have to track its usage and level against your total code/assets.

Like credit card debt, too many people turn around and they've got $20k of credit card debt or 20k LOC of tech debt.

I don't have too much of a problem with tech debt as long as: the benefit is clear; the debt is well understood; the payoff date/cost is planned. Just last night I was talking with a developer who works for me: "This way will require 5 queries instead of 1. Can you help me figure out this whacky ORM API to do it in 1?"; "Just do it as 5 right now and, as we learn more about the ORM API, we'll fix it later..." Tech debt: we get the product done faster; we've got a 1-5 line change to make (when we know how to make it); and we'll do so in a few months.

[pak9rabid]

>and we'll do so in a few months.

Ah, famous last words that I myself have also spoken from time to time.

[nullsense]

Yup. Mentally I pipe everything any devs, including myself, say through a sed command like this:

s/for now/forever/g

[iainctduncan]

Yes, this is totally on the money. This is exactly what we want to see when assessing tech debt on an acquisition assessment (I do tech diligence for acquisitions). If you do it for good reasons, and you track it, and you proactively allocate resources on an ongoing basis or make tech debt remediation a first class road map item, it's not a problem, it might even be a good thing. If you wracked it up playing fast and loose and being all "go fast and break things", it could cost you the deal, or millions of dollars off the deal price.

[heelix]

I love this analogy. Dealing with a minor set of updates ... that now need to be done in 60+ all slightly different codebases for this weekend. I'm using it in our next chat with the business side.