What Technical Debt is & how it is measured?
Technical debt (also known as tech debt or code debt) describes what results when development teams take actions to expedite the delivery of a piece of functionality or a project which later needs to be refactored. In other words, it’s the result of prioritizing speedy delivery over perfect code. Technical debt describes the consequences of software development actions that intentionally or unintentionally prioritize client value and/or project constraints such as delivery deadlines, over more technical implementation, and design considerations.
Technical debt refers to the practice of making coding or design decisions to expedite production or gain other short-term benefits, knowing that these decisions may require corrections later. Like financial debt, technical debt offers both benefits and costs.
Technical debt is not necessarily a bad thing, as long as you know how to manage it. Consider this expert advice on how to measure it and when to pay it off.
Different Types of Technical Debt
In 2007, Steve McConnell suggested that there are 2 types of technical debt: 1. Intentional — According to him, intentional technical debt is technical debt that one takes on consciously as a strategic tool. 2. Unintentional — As opposed to unintentional debt, which he calls “the non-strategic result of doing a poor job.
How to measure Technical Debt?
It doesn’t help decision-making if we can’t place a number on such an important concept. Once we can quantify it, we can make analytical comparisons, we can know if we’re making progress, we can plan with data. Non-technical team members can get an understanding of the quality of the software upon which the business runs. But so many variables are involved in determining code quality, of which technical debt computation is an important factor. Some of these variables include complexities [cyclomatic and cognitive], lines of code, arity, maintainability index, Halstead Complexity Measures, depth of inheritance, afferent and efferent couplings, nesting depth, time to write n lines, etc. With so many metrics to consider, it appears difficult to know how much work we need to do to pay off technical debt.
It turns out, however, that there’s a simple solution to this problem — it lies in how we choose to express the problem:
Express technical debt computation as a ratio.
A ratio of the cost to fix a software system [Remediation Cost] to the cost of developing it [Development Cost].
This ratio is called the Technical Debt Ratio [TDR]:
Technical Debt Ratio = (Remediation Cost / Development Cost) x 100% Really simple isn’t it! Technical Debt Ratio [TDR] is simply the ratio of remediation cost to development cost
Generally, no one wants a high Technical Debt Ratio [TDR], some teams favor values less than or equal to 5%. High TDR scores reflect software that’s in a really poor state of quality.
If both remediation and development costs are represented in time [hours], for example, TDR scores simply indicate how long it would take an engineering team to restore sanity to their codebase and achieve quality. So smaller TDR values are to be preferred at all times. Prefer smaller TDR values at all times.
Remediation Cost [RC] can be made a function of any code quality metric a team feels is relevant based on rules for resolving code issues within the team. RC can also be expressed in terms of time.
For example, if the team chooses to make RC [expressed in time] a function of cyclomatic complexity, in other words, the time it takes to fix issues within a code function — RC, is directly proportional to the cyclomatic complexity of that code function, then it becomes easy to determine how long it would take to fix entire files once we compute their cyclomatic complexities. This is just an example , we won’t be discussing the computation of cyclomatic complexity here.
Basically, for this line of reasoning:
RC α Cyclomatic Complexity
RC = k(Cyclomatic Complexity)
where k is a constant
Once k and Cyclomatic Complexity above are given, RC can be easily computed.
Development cost [DC] can be imagined as the cost of writing some lines of code [the time it took to write that much line].
For example, if a file has 100 Lines Of Code [LOC], and it takes an average of 0.27 hours to write one line, that is, Cost Per Line — CPL, is 0.27 hours, the development cost [DC] would be: 0.27 hours/line x 100 lines = 27 hours. This means it took 27 hours to develop the code in that file
Now that we have all the relevant variables for TDR covered with their associated abbreviations, let’s remind ourselves of the abbreviations again:
Development Cost: DC [hours]
Lines Of Code: LOC [lines]
Cost Per Line: CPL [hours]
Remediation Cost: RC [hours]
Technical Debt Ratio: TDR
So, referring back to the definition of the TDR, we can write:
TDR = ( RC / DC ) x 100%
Where: DC = CPL x LOC
