The meta definition of debt goes something like this:
“A debt<T> is created when a creditor<T> agrees to lend a sum of assets<T> to a debtor<T,R>.
In modern society, debt<T> is usually granted with expected repayment; in most cases, plus interest”
In other words, If you borrow something, etuiqette dictates that you pay it back – especially in instances of debt<money>, with interest. If you don’t, bad things will happen to you, and you’ll probably end up having to sleep under a bridge – with aching knee caps as a possible consequence of using the wrong T for creditor (chosing creditor<bank> is usually a better idea than creditor<Tony S>)
In the case of debt<technical>, creditor<enterprise>, asset<time>, “debtor<T>” gets interesting.
It is worth mentioning that the consequences of technical debt actually varies according to the developer’s religion. Islam prohibits lending with interest, so a debtor<developer, Sheik Yerbouty> gets away with paying less than an instance of debtor<developer, Catholic girl> where interest has been a concern since the days of Charles Babbage. On the other hand, an instance of debtor<developer, Jewish princess> implementing an especially inefficient piece of code, will literally get away with technical murder (According to the Torah, all debts should be erased every 7 years and every 50 years)
Another consideration is that we (for the type definitions above) actually need two instances of debtor<T>. This is because one usually goes out of scope before the transaction is complete. This is especially true for the pair<debtor<consultant>, creditor<enterprise>>
To complicate matters further, the semantics change dramatically across the domain of type parameters.
In the case of debt<financial>, creditor<institution>, asset<money>, debtor<Joe> we have just defined the driving force behind the global economy, growth and prosperity.
If we switch back to the technical debt type parameterization scenario, we end up with the unit-testing mafia’s classical rhetorical dilemma “pay now or pay more later ?”. In this case debt is interpreted as bad and should therefore be avoided at all costs. Unfortunately, their intepretation is based on their inability to grasp the concept of two temporally coupled instances of debtor<T>
Technical debt is a good thing. It’s what makes the IT world spin. Without it, every system would work flawlessly and be so easy to maintain and extend that 95% of us would be out of a job – and therefore probably end up having to sleep under a bridge. There is actually an argument to be made for a significant global increase in the aquisition of technical debts.
1: An enteprise with a large technical debt will likely require the services of an increasing number of developers to keep things under control (and probably also additional manpower to compensate for the software’s inability to support the core business processes). More developers will introduce more technical debt and the cycle continues. Eventually everything will collapse and the original software has to be replaced by new and improved software. Fortunately the introduction of a piece of new and complex software requires the services of domain- and software experts. If the software gets complex enough (and it will, if the debt is large enough), one will have to refer to the previous implementation to be absolutely sure that all the implicit knowledge contained in the old implementation is transfered to the new implementation. This includes representations of data and logic. If (reader<executive> == typeof(you)) Goto 1;
Debt is good. It’s very, very good.
It provides more jobs than any enterprise can ever get rid of by downsizing. If they select the outsourcing option, the technical debt increses even faster because of a higher technical interest. In addition to this, it will also (eventually) drive your salary skywards due to the fact that educational institutions don’t scale, but technical debt does – exponentially.
Normality and semantics are hereby restored.
[Ed: Some definitions may accidentally have been ripped from Wikipedia in the process of writing this article]