The need to move fast is often associated with productivity. In software engineering, productivity boils down to releasing features quickly and often. These two attributes easily please the ones explaining progress to stakeholders. However, the need for speed often easily neglects direction. This results in compromising code quality for shortcuts, let alone not asking the question of a looming technical debt ratio.
This post reviews the common scenarios that determine a team’s technical debt ratio. We’ll explain how it can be quantified. When known, we’ll also discuss the best ways to keep the ratio within a reasonable range.
Let’s start with clearly defining what technical debt and the resulting ratio are.
Table of Contents
- What Is Technical Debt?
- How to Calculate Technical Debt Ratio
- What the Technical Debt Ratio Means
- Talk About Your Technical Debt
What Is Technical Debt?
For every impending software change, there exist two ways of getting things done. One way involves tying together new changes and the good logical flow of the system from the core. It’s the right way of versioning. This results in feature flags and multiple iterations of tests in as many test environments as you need to mitigate any bugs in the future.
The other way of versioning a software product is typically an overnight code session of patches and features. These skip stages to deployment just to make sure we meet deadlines. Where the reasonable code route would have taken longer, the fast fix is applied and a statement usually makes this all okay: “We’ll revisit this when we have time!”
The moment you let the “patch now, fix later” mentality fester, you start growing technical debt. Your codebase loses quality points in favor of growth. You owe the codebase some attention—hence, the debt. It’s a feel for how much it will cost to refine the codebase.
The Ratio
More important than feeling in debt to your aging codebase is the technical debt ratio. Before we explain the ratio, admit that each time you compromise and add bad code in the name of speed, the underlying codebase rots due to lack of maintenance. This means your technical debt actually accrues interest in work hours.
The ratio comes into question when we factor both the time it takes to fix the codebase and the cost we’d incur due to remediation efforts.
Technical Debt Ratio => Time to Fix Codebase : Cost to Build It
The ratio makes more sense once we dismantle it. Keep reading.
How to Calculate Technical Debt Ratio
Like any statement that should inspire decisions, we’re best normalizing both the time and the costs involved. There are various ways to measure technical debt. We’ll use one strategy here: The cost to build can be calculated by gauging how long a line of code takes for your developers to churn out, and the total LOC in a particular section of code.
The time it takes to fix the codebase can be pulled from consensus. It’s wise to base how long it will take to fix something on how complex it is. You could point to several metrics like the lead and cycle times associated with tasks of the same nature. However, they too are often measured while you were in the process of building technical debt.
Let’s run the logic on a practical scenario. Say developers and project managers have agreed that it’ll take roughly 400 hours to remediate the codebase, and it has 30,000 lines of code. They need only agree on how long it takes to write one line—say, 0.2 hours per line.
With these variables, you already have one side of the ratio: 400 hours.
Once you work out how long it takes to code 30,000 lines at 0.2 hours per line:
(30,000 * 0.20 = 6,000),
a ratio of 400:6,000 is basically 1:15—which, when you weigh it as a percentage, [(1/15)*100] = 6.67%.
What the Technical Debt Ratio Means
From a business perspective, the technical debt ratio is a set of numbers that engineering management must keep an eye on for the sake of progress control. We’re talking about actual progress here. At some point, there should be a decision to assign a portion of developers to tasks that reduce technical debt.
Our recent Engineering Benchmarks study on What Makes Engineering Teams Elite revealed that the top 10% of engineering teams consistently have a rework rate less than 8%. But most of the teams we studied were having to designate more than 15% of their work to fixing code older than 21 days.
The tricky part is that when developers revert to old code, any work done to maintain the parts added in a rush further adds to bad code. And, in turn, this adds debt. As such, the first thing to note is which parts are good, and separate them from those made as quick fixes. It’s like peeling off bad layers to start working on rotting sections of the previously perfect codebase.
On the extreme end of the spectrum, a technical debt ratio of 1:1, which evaluates to 100%, just confirms that your codebase is a write-off. At this point, it takes just as much effort to fix your codebase as you would be asked to pay to build it afresh. In fact, assigning developers to work on such a scenario would be asking them to purge your entire codebase.
Unless you have more developers than you know what to do with, the question isn’t if you’re doing it or not, but how to keep technical debt ratios under check.
How to Keep the Ratio Favorable
You may have heard some good developers pledging time in payment for a service. Yes, the attention of a very good developer is worth a lot. It doesn’t even have to be directly on new features. In fact, when you get that attention invested in chewing into your technical debt, you gain more than you could have if they paid their dues in cash. Increased product longevity!
A few things you could do to keep the technical debt ratio in check include:
- Assigning ample time to the design phase: Start at the root cause of technical debt—design. This is where a game of snakes and ladders begins with the quick ascension to completion despite the risks of getting bitten by bad design in the future. Sometimes development begins even before prototypes do the rounds.
- Recalibrate stakeholder expectations. Bore it into your team that you could do things fast, or you could do them correctly. While first to market is the holy grail in marketing terms, best to market works better when going the distance. To get teams on board, make sure to remove gaps in knowledge by making operational metrics known at the managerial level. Look into data visibility on this part.
- Stick to best practice methods. Shortcuts are seldom on the industry-standard list of means to do things. While you can hack your way past blocks of tasks with a duck tape line of thinking, you’ll only spend double time (or more) with proper fixes in the future. The sad addition of code on bad code in the name of maintenance just scales the problem at hand.
Talk About Your Technical Debt
Without sounding like AA, make it a habit to speak out about your technical debt. The pressure to fix it becomes more bearable when more than just one engineer is aware of the growing ratio. If everyone keeps quiet, it could be too long before you discover that you’re now working on a project that requires too much attention for it to catch up with standards.
This is really the main benefit of metrics: They spark awareness and conversation. The technical debt ratio is perhaps the most powerful metric to help you combat technical debt but there are others, which you can read about here, that will help you create a culture within your teams of being mindful of technical debt.
You don’t have to be in conversation with teams under your particular organization. In fact, join LinearB’s leadership Discord community or attend our next Interact conference to talk about tech debt in codebases. This way, you can learn how other engineers are fixing theirs. In turn, you can adopt the best ways to keep yours in check.
