@adlrocha - The Risks of Technical Debt
Technical debt should be one more item on a company’s balance sheet.
I am going to be completely honest, I am starting this publication without a clear idea of what I want to write about. I just came up with the title and started writing. Oh wait, good idea! Let’s start from there, the story of what led me to this title.
The other day, I was discussing with someone from a venture capital firm about their technical due diligence, and their methods to evaluate the technical strengths and weaknesses of the companies they invest in. At one point in the conversation, we started sharing examples of companies with product market-fit and financial health that ended up crushed by their technical debt. It wasn’t financial debt what burned their funds, but having to maintain and pay all the technical debt they were sitting on while they tried to scale.
Even so, there are venture capital firms who still invest in companies whose technical debt is a clear “no-go”. Can this be prevented in some way? We concluded our conversation realizing that there may be a good solution for this: to include technical debt as an additional item on a company’s balance sheet. This would enable the folks at finance and the investment board (potentially with a less technical background) to interpret this metric on their own language.
What if we could come up with a clear objective metric for technical debt (with a principal and an interest rate like traditional debt). Thus, when the time comes for the investment board to make their decision, they have an objective way to include technical debt into their decision making process (with numbers to crunch). Investors will definitely start appreciating the importance and potential risks of technology for a company, while product teams will take a step back every now and then to understand the state of their debt. But to objectively quantify technical debt, we first need to know what does this debt look like?
“In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.”
What does technical debt look like?
We can define technical debt as “important work that has been delayed but that will need to be done in the future”. We can all agree that technical debt generally appears when we prioritize a speedy delivery over code quality. This is a common occurrence in early startups where the resources are limited, and the priority is to ship an MVP of the product so that investors and the market can get a glimpse of their potential. So in certain cases leveraging technical debt, like financial debt, is OK, as long as it is managed with the caution it deserves.
Technical debt may appear in different forms:
Bad architectural choices.
Lack of documentation.
Use of outdated, unmaintained, or poorly documented technologies and frameworks.
Lack of deep knowledge about the system being built and the technologies being used.
Lack of testing (both functional and load).
Lack of automation in the development process.
Lack of a measurement (the fact that you have no idea of what is happening with your system).
Under-maintained internal project code bases.
Poorly chosen variable names. Messy code bases.
Poor communication between the members of the development team.
Misaligned goals, and wrong prioritization.
Lack of skills and talent (and this tightly links with the company’s culture. But more about this some other time).
Building the wrong team and establishing the wrong culture.
Not taking care of your team members.
(For reference, I came up with this list myself, so it may be missing a lot of things, feel free to comment with more causes of technical debt for me to add them here).
After coming up with this list, I started researching about the matter to see if I could complement it in any way, when I found out that there are papers formalizing and categorizing technical debt. A good example is “Towards an Ontology of Terms on Technical Debt”, which identifies 13 distinct types of technical debt and a set of key indicators for each of them.
Architecture Debt
Build Debt
Code Debt
Defect Debt
Design Debt
Documentation Debt
Infrastructure Debt
People Debt
Process Debt
Requirement Debt
Service Debt
Test Automation Debt
Test Debt
“Technical debt is anything (code-based, or not)that slows or hinders the development process.”
Martin Fowler’s Technical Debt Quadrant
Measuring it and acting upon it!
Technical debt can be anywhere. To measure it right, the first thing we need is a way to identify it. This alone is an extremely difficult task, but once we’ve managed to do so, we are ready to measure its impact. How can this be done? Well, there is no one better to measure the debt’s impact than the team involved in the development. The same way sales departments make predictions of future sales, your development team will have to learn how to make periodic assessments of the pile of debt they are sitting on. A good way to do it is through the Technical Debt Ratio (TDR).
TDR (%) = (Remediation cost / development cost) * 100Remediation Cost 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.
Development cost can be imagined as the cost of writing some lines of code [the time it took to write that much line].
You can clearly see why I said that the only ones able to “objectively” measure this is the team involved. Each company can come up with their own way of computing the remediation and development costs. The literature out there claims that teams should aim to have their technical debt always below 5% (provided they are measuring it consistently, of course) but as with financial debt, this is completely up to the parties involved.
But even if the objectivity of this measure can be argued, measuring the TDR has many interesting consequences. The same way a financial due diligence can check that your financial numbers match up, once the TDR is standardized in a team, a technical due diligence (or an external auditor) can assess the awareness of a team with its blunders in a more consistent way.
Even more, measuring the TDR forces the team to get proficient on the identification of technical debt. And once identified and measured, paying a technical debt is just a matter of management and prioritization, nothing that you are not already used to doing on a daily basis.
Looking at technical debt as financial debt
Returning to the initial conversation that led to this publication, let’s see if we can do an exercise of creativity and derive from the TDR something closer to financial debt for our financial friends to understand its impact better. After seeing there were papers about technical debt, I was curious to see if someone had formalized and came up with this analogy before. Unfortunately, I came across many interesting papers, but nothing usable. So I gave it a try myself!
The aim of this analogy is to be able to represent technical debt in a balance sheet like if it was long-term financial debt. Let’s assume technical debt is re-computed every quarter in order to include it in the company’s quarterly results. This translates in a quarterly reevaluation of the TDR. In addition to the TDR, you will also need to know the development costs for the quarter in order to account for the total development costs of the project/product. With this, the technical debt in dollars (or your cryptocurrency of choice) can be computed as:
Technical debt (Qi) = Total Dev. costs in Qi * TDR increase QiConsequently, the technical debt for a year considering 10K$ of development costs per quarter (I wish!) would be:
TDR (Q1) = 2%; Total Dev. costs = 10K$
TDR (Q2) = 3%; Total Dev. costs = 20K$
TDR (Q3) = 4%; Total Dev. costs = 30K$
TDR (Q4) = 3%; Total Dev. costs = 40K$
--------------------------------------------------
TDR(Year) = 0.2K$ + 0.2K$ + 0.3K$ - 0.4K$ = 0.3K$Increasing TDR in a quarter increases debt in that proportion of the total development costs, while reducing it reduces debt accordingly. The more development costs you accumulate, the more advanced the project potentially is, and hence the higher “the principal” and the financial impact of the technical debt. On the other hand, the higher the principal the higher the reduction of the technical debt if the TDR is decreased in the quarter.
Of course, this is just a toy example. There are several way in which this analogy could be further improved. But as a first iteration I think it suits well what we were aiming for initially. Do you want to start testing this metric? Please do so, and report me back the result so we can write a follow-up publication.
Capitalism without capital
Software and technology are becoming increasingly important for our society and our companies. But something we need to realize is that technology and software can be at the same time a competitive advantage and a potential risk. Being able to identify these risks early is key for the success of a product, a company, or a society.
I have stated several times in this newsletter the importance of well-designed software. I hope this publication is a new small contribution to this school of thought. Some of you may be thinking while reading these lines, “what a dumb idea, including technical debt in the balance sheet”. Well, let me tell you that I am not the first one proposing something like this. We are living in a capitalism without capital, and we should upgrade many of our current metrics to accommodate for this fact.
Final note: I am working on a few new interesting features for this newsletter, I hope to have the time in the next few weeks to finish polishing and get in up and running. Stay tuned!