Towards an understanding of technical debt

Towards an understanding of technical debt
laughingmeme.org

Like real life monetary debt, technical debt has 2 aspects: the principle and the interest. Sometimes the interest ends up being variable rate and backbreaking for your project - you should have written those tests up front and saved yourself a lot of time. Sometimes the whole project dies before you pay back the debt - you go bankrupt but it's no big deal, your creditors are friendly. In either case, the principle usually isn't smaller when you go to address it. You're just delaying payment in favor of speed.

What the original artical addresses are several aspects that I might call "technical assets" that have depreciated significantly. That kludge, if it wasn't done intentionally, isn't debt - it's now an asset. If you didn't have a plan to pay it off in the future, you've already bought it and now you need to replace it. And the replacement is very expensive. That is a technical investment you're deciding to make. You aren't just paying off debt at that point, it's a whole new capital expense.

If you look at a practice like Unit testing, you tend to find some organizations are having success with it and others not. Some of them see it as a "waste of time" and others see it as a "timesaver". How the practices are implemented are as important as the practices you decide to use. If the unit tests for your project take 3 minutes to run you may have a problem. If you are writing a large number of hard to maintain mock objects you may have a problem. If the program is not divided into units that are easy to test that is a different problem.

Another good example is the use of Vagrant. It is very possible to have Vagrant spinning like a top, but in a lot of places you hear software management grumbling that a team of 3 people wasted 2 weeks screwing around with it.

I see it so common for developer discussions to center around "cargo cult" positions (i.e. "singletons are evil") and not around a real dialog about the work to be done and how to do it.

One of the other problems with the technical debt idea is, debt relative to what? Since I think most people do not consciously instantiate an answer to that question, I think most of us non-purposefully choose by default a comparison to an idealized perfect code base that is somehow perfectly correctly factored, yet also as fast as completely optimized code, completely documented without being overdocumented, simultaneously optimized for all possible future changes, and despite not existing at the moment, also perfectly understood by the original team such that they can do anything they like to it, and such understanding will survive any such refactoring, all accomplished in exactly the same amount of time that it took to write the terribad code that we actually have.

OK, but that was never on the table, though. What I described isn't even possible to manifest, and even if you back it down to what is at least sort of possible, you don't have the resources to manifest it before you simply run out due to lack of customers. You're not really taking on "debt" if you fail to manifest that, any more than you are taking on "debt" if you fail to make every possible dollar you could if you perfectly correctly harnessed your skills and made the perfect deals.

I think what a lot of people call "debt" is simply the natural state of code. Debt is something somewhat more exceptional than that. There is a core idea of value there, because there definitely is an operation where we deliberately make a short-term choice at the cost of long-term pain, but it requires more thought than I think has traditionally been given to it. The baseline needs to be more carefully defined.

As I said at the top, I'm just musing here; I don't have a ready-to-go definition of "baseline quality" here.