Technical Debt

Technical debt is the amount of work needed to decrease the total cost of a product.

Me

The classical definition doesn’t work

Technical debt (TD) is intuitively easy to grasp as an inherent quality/complexity issue that makes a product hard to operate and change, which is a good description but not a good definition of the term. Even Wikipedia stays true to its encyclopedic nature by avoiding a definition in favour of a phenotypical reproduction:

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.

https://en.wikipedia.org/wiki/Technical_debt

This non-definition doesn’t relate technical debt to tangible project KPIs like effort and cost and thus makes it hard to explain to project managers and hard to put a price tag on.

A new definition

Technical debt is the amount of work needed to decrease the cost of a product.

A synonymous definition (it will become apparent later why this is the case) is the answer to the question:

How much does it cost to reduce cost by X?

A useful formula for cost estimation which comes to mind would be:

Product cost = cost of development + cost of change + cost of maintenance + cost of operation

If I wanted to reduce the product cost, I would try to reduce the constituent costs by increasing quality and efficiency. The work that goes into increasing quality and efficiency has, also, a price tag on it – that price tag is technical debt.

Let’s look at some consequences of this definition which relates technical debt (TD) to maintenance cost in contrast to the classical “definition” (CTD) related to quality and complexity.

§1 Technical debt is about cost reduction

As opposed to the classical definition, the new technical debt (NTD) definition is not about technical quality per se, nor about inner beauty or paradigm purity. If a change does not result in a ToC (total cost of ownership) reduction, then that change did not reduce technical debt.

§2 TD includes maintenance and operation

TD relates to the ToC of a product, including maintenance and operation. The new definition does not only relate to the cost of change, but includes the cost of operating instances, keeping a development team busy etc. For example, even a well designed product incurs high operational cost if it requires a dedicated, obsolete infrastructure (as opposed, eg., to a modern and abundantly available cloud infrastructure).

§3 The classical definition of technical debt is ambiguous

Let’s imagine the perfect product with no technical debt, with absolutely no superfluous code for not-yet-requested enhancements (because, if the product supported more functionality than required, it might include unnecessary code). The code base is tight like a quasar. There are no unnecessary abstractions, components invoke each other through tightly coupled interfaces because coupling them loosely would require more code – do you see where this is going? Actually coupling components loosely is considered a practice which increases software quality, but it comes at the cost of increased code complexity. If the aim is to reduce product complexity while still matching the original set of requirements, then loose coupling is a bad thing. If requirements include extensibility, then loose coupling is a good thing. The new definition of TD incentivises architectural styles which aid functional requirements.

§4 Technical debt relates to the fitness for purpose of a product

The requirement “I want to call my parents” is equally well served by a landline phone and a smartphone, with a landline phone being simpler and cheaper than a smartphone – a smartphone would be overly complex and incur considerable TD reflected in higher cost of operation. But when the requirement “I want to send them photos” is added to the product backlog, the more complex product (with ostensibly higher TD) suddenly not only is better suited to the purpose, but it has lower TD than the landline + camera + printer + fax machine product increment because it is cheaper to operate.

§5 Technical debt depends on context

Classical TD (CTD) inspects inherent technical product qualities and implies that TD be absolutely quantifiable (although I showed in §3 [ambiguity] that it is not). The new definition (NTD) tries to answer the question “how much does it cost to reduce cost by X”? A product with large TD may achieve significant maintenance cost reductions with a modest investment in quality. On the other hand, a product with already low TD might require significant efforts to reduce that debt to even lower levels. TD also depends on who is implementing changes; an experienced team using appropriate tools and techniques may find TD smaller than a less capable team.

§6 Technical debt ≠ technical debt

There is a significant difference between the NTD and CTD definitions. With CTD, an impeccable technical architecture implies low technical debt, even if operational costs are high. The NTD definition necessarily mandates that low technical debt leads to low operational cost. For example, a succinct, clean architecture incurs low maintenance cost (smaller developer team, fewer bugs) but might perform badly under load and require expensive infrastructure. A more complex architecture might incur a higher maintenance cost (more developers, more bugs) but might perform better, requiring a smaller infrastructure footprint. Depending on the situation, maintenance cost may outweigh operational cost and vice versa; in any case, the definition of NTD follows the overall cheaper solution.

§7 NTD is relative

Having in mind §3 (CTD is ambiguous) I’ll leap ahead and claim that NTD can be reduced to zero while CTD can’t. First of all, CTD isn’t quantifiable – so how could it be 0? But assuming it were, we’ve already seen an example where the same change (coupling) both increases and decreases CTD at the same time because the evaluation of change’s complexity are conflicting. The NTD allows for the extreme case of reducing debt to zero, namely paying a large up-front amount in order to build an outsourcing company which will take over maintenance and operation of the product. This answers the question “how much does it cost to reduce cost to zero?”, and the answer is “it costs as much as completely outsourcing the product”. This observation is even more so plausible taking §5 (TD depends on context) into account. The issue here is that NTD is zero for us, but the outsourcing company which took over product maintenance just bought a significant NTD, so that’s the first cause of relativity: NTD depends on organisational context.

Conclusion

The new definition of technical debt I’m proposing directly correlates technical debt with quantifiable effort needed to reduce the cost of a product. The new definition moves technical debt out of the subjective and controversial focus of technical quality and make it measurable quantity that can be reported and acted on.