{"id":5984,"date":"2015-11-12T06:00:06","date_gmt":"2015-11-12T14:00:06","guid":{"rendered":"http:\/\/thinkapps.com\/blog\/?p=5984"},"modified":"2015-11-11T15:59:35","modified_gmt":"2015-11-11T23:59:35","slug":"technical-debt-calculation","status":"publish","type":"post","link":"https:\/\/thinkapps.com\/blog\/development\/technical-debt-calculation\/","title":{"rendered":"How to Calculate Technical Debt and Express It Clearly"},"content":{"rendered":"

This is the second post in our\u00a0series on technical debt<\/a><\/span>. In the first post, we explained what technical debt is and why it’s important<\/a><\/span>. Now we’re exploring technical debt calculation.<\/em><\/p>\n

It\u2019s been several weeks since my “Technical Debt 101”\u00a0blog post. As promised, it was the first in\u00a0a series about this silent danger that is eating our software. <\/span><\/p>\n

I hope you enjoyed the kitchen metaphor and can now\u00a0clearly identify the different “flavors” of technica<\/span>l debt. After reading the first post, you\u00a0should also understand how quality is affected by poor and “dirty” code and when is the right time to deal with technical debt. <\/span><\/p>\n

In this second post, I will explain how to calculate\u00a0technical debt and express it in a way that’s easily understood by both technical and non-technical team members.<\/h3>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

What Should the Numbers Tell Us?<\/span><\/h2>\n

I’ve given many\u00a0talks at development conferences.\u00a0All of my presentations include at least one slide with numeric data\u00a0based on research, an analysis I conducted, or another reliable source. <\/span><\/p>\n

These metrics are simple, easy to understand, and objective. I do this in order\u00a0to explain to the audience\u00a0that realistic and accurate numbers can drive me to the right decisions. On the other hand, numbers that are hard to understand or wrongly computed can lead to\u00a0choices that will cost me time or even money, in some cases. <\/span><\/p>\n

Technical debt epitomizes\u00a0my philosophy. It\u2019s a critical factor of code quality measurement (and management). Companies simply can\u2019t afford miscalculations or reports that are hard to interpret.<\/p>\n

Moreover, technical debt should be easily communicated to non-technical team members, such as upper management, business people, product owners, and even customer representatives.<\/p>\n

It might seem strange\u00a0to share an \u201cinternal\u201d code quality metric with the customer. But let\u2019s remind ourselves that it\u2019s the customers who\u00a0invest in our software, and they deserve to know where exactly they’re putting their money.<\/p>\n

What is the best way to express technical debt without using technical jargon<\/a>\u00a0so that everyone is able to understand it?<\/h3>\n

Developers use a variety\u00a0of terms for code quality metrics, such as cyclomatic complexity<\/em> or branch coverage<\/em> or unwanted dependency cycles<\/em>. <\/span><\/p>\n

All of them look like Greek<\/span> to business and product people.* If we asked them what value they get from such metrics, their answer would probably be\u00a0“none.”<\/span><\/p>\n

*Since I\u2019m Greek, my sarcasm about my mother-tongue is allowed. \ud83d\ude42<\/span><\/em><\/p>\n

In the following paragraphs, I’ll discuss how to calculate the most important metrics affecting technical debt and will present the debt\u00a0as a single reference number.<\/strong><\/p>\n

Before we move forward, however, let me add one more parameter. In my previous post, we discussed\u00a0that there are many types of technical debt (i.e. design, defect, testing, and documentation). We also explained that there are various root causes that increase technical debt. <\/span><\/p>\n

Every root cause can be represented by one or more metrics, but ideally we want to express technical debt as a single number that will describe the overall quality of a software system. Moreover, we want to\u00a0<\/span>find a metric that makes sense to both technical and non-technical folks.<\/p>\n

Before we do that, however, let\u2019s step back for a minute and think about financial debt.<\/p>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

Comparison to Financial Debt<\/h3>\n

If I go to a bank to ask for a loan, I will talk\u00a0with the bank representative about the amount of money that I need and\u00a0how much I can afford to pay back every month.\u00a0I will also sign a loan agreement that clearly states the above details and the number of\u00a0months I have to\u00a0repay\u00a0the loan.<\/p>\n

Wouldn\u2019t it\u00a0make sense to\u00a0express technical debt in a similar way? How about telling the business that in order to eliminate all or \u201cX%\u201d of the technical debt, the development team needs to spend \u201cY\u201d man-days working on it?<\/p>\n

Wouldn\u2019t that make perfect sense? Isn\u2019t this a number that is easily understood by all stakeholders?\u00a0Yes, of course!<\/p>\n

Developers perceive this as the number of days they have to spend in order to write unit tests (increase coverage), remove duplicate code, do refactoring (decrease complexity) or any other activity that will help them eliminate the technical debt.<\/p>\n

Meanwhile, this calculation says to non-technical team members:\u00a0“If you want to improve the quality of your software \u2014 by paying back the technical debt \u2014 you need to ask the development team to spend\u00a0Y man-days on it.\u201d<\/p>\n

We can take it one step further:\u00a0If this number is multiplied by the average rate of the development team, then we can easily compute the cost of this effort in any given currency.<\/p>\n

This approach is great because management is able to forecast how much money (and time) it will cost to put the software back on track for the desired level of quality.<\/p>\n

\"Technical<\/a><\/p>\n

Image credit<\/a><\/em><\/p>\n

What\u2019s Happening Behind the Scenes?<\/h2>\n

At this point, you’re probably wondering how all of these technical metrics can be boiled down to a single number. <\/span><\/p>\n

The first step is to measure everything that contributes\u00a0to the technical debt: code duplication, code complexity, test coverage, dependency cycles and coupling, lack of documentation, and\u00a0programming rules violations. <\/span><\/p>\n

Let me briefly explain how to calculate each of these technical debt components. <\/strong><\/p>\n

Code Duplication<\/h3>\n

Duplicate or copy-pasted code is usually expressed as the ratio of duplicated lines to the total lines of code within a\u00a0range of 0% (no duplications \u2014 perfect score) to 100% (everything has been copied and pasted at least once \u2014 although I doubt you’d\u00a0ever find such a project!) <\/span><\/p>\n

There are many algorithms to detect duplicate code. It seems that the most popular one is to examine the same series of identical tokens with some occasional variation (adding or removing tokens). A token is the simplest programming language element such as an identifier, a keyword, a separator, an operator, a literal, or even a comment. <\/span><\/p>\n

What a duplication detection mechanism does is split the lines of code into tokens, set the minimum number of identical tokens that can be considered duplicated code, and then search the code for the same series of tokens. <\/span><\/p>\n

By utilizing this process for the complete codebase, it\u2019s easy to compute the number of duplicated lines of code and divide them by the total number of lines of code to get the percentage referenced above. <\/span><\/p>\n

Code Complexity<\/span><\/h3>\n

Code complexity<\/span> can be expressed in many ways. The most widely-known metric is the cyclomatic complexity,<\/em> which in simple words is the total number of different paths in a code unit (method, function, class, etc.). <\/span><\/p>\n

Every unit of code by default has a complexity of one. Every branch in the code (if, case, switch statements) adds one to the complexity. Every exit path or exception (valid in some programming languages) also adds one to the overall complexity. <\/span><\/p>\n

Although the accepted complexity per programming unit might vary from language to language or system to system, the following rules and ranges have been proven to work in most cases:<\/span><\/p>\n