If you are even remotely related to software development, you must have heard of and experienced ‘technical debt’ in some or the other way. In this article, I am going to talk about what is technical debt, how to calculate technical debt, types of technical debt, and how to reduce technical debt in your software development project.
Here’s a hard-to-swallow-pill for you. Unless you live in a fantasy world with a dream development team that follows Agile Methodologies and never takes shortcuts or easier trade-offs to meet tight deadlines, technical debt is bound to happen!
Before you get all critical, I’ll explain the reason behind this.
No matter how large your development/design team is, there is always a real battle going on in the background – meeting tight delivery deadlines vs delivering future-ready pristine code is always there.
When I say “future-ready,” I mean code that is not just “good enough” but is also scalable and easily allows future integrations & iterations without having to redo everything from scratch.
While technical debt is an inevitable part of software development, this doesn’t mean you cannot effectively manage it. So, how can you reduce technical debt in your dev project? But before that, let’s quickly look at what is technical debt and its various types.
What is Technical Debt?
Technical Debt in software development – be it app development or other, is the cost of additional resources needed to rework a piece of code (for future integrations, additions, etc.) because the development team chose an easier way (instead of going through the longer, better way) for quick delivery.
A one-line definition of Technical Debt would be – the implied cost of a tradeoff between ‘perfect’ code and tight project delivery timelines.
In a software development life cycle, we hear phrases like “we’ll visit this later when we have time” all the time. You, as a technical head or an entrepreneur, know this better than anyone this ‘later’ never comes (well, at least in most cases).
Keep in mind that the word “Debt” is not just a hypothetical term or something that is being carried around for no reason.
Technical Debt is ACTUALLY a debt – the incurred cost of poor implementation of code/design in software development taken for moving quicker in the SDLC as compared to implementing better, unique, scalable, and future-ready code/design that takes longer.
To understand the true horror of Technical Debt, you must see it as a recurring/ongoing “extra” cost than a one-time payoff. Ward Cunningham, inventor of the first Wiki & founder of Agile explains this well.
He says – “With borrowed money, you can do something sooner than you might otherwise but until you pay back that money, you’ll be paying interest.”
Now, I want you to read the above quote again after changing the below-mentioned phrases with their respective replacements to really understand why you should reduce technical debt in your dev project.
Borrowed money – Redundant/imperfect/good enough code
- Do something sooner than you might otherwise – deliver quicker or meet tight software deadlines
- Payback that money – Fix/upgrade your software with original/scalable
- Interest – Recurring, extra maintenance/upgrade costs
How is Technical Debt Calculated?
This is probably the sub-section you have been waiting for. As they say, “you can fix what you can’t measure.”
You want to know the real numbers and how to calculate the said cost for your project before you can actually work to reduce technical debt. So, how to measure Technical Debt?
Before we get into the formula, here are three phrases that you need to know.
Cyclomatic complexity
The cyclomatic complexity of a development project, in a nutshell, defines the number of linearly independent code blocks. This complexity is calculated during static analysis of a code using Control Flow Graph.
I am including cyclomatic complexity here because most development teams use this metric to assess and reduce the code complexity of their software development projects.
Here is a simple demonstration of how the cyclomatic complexity of a code is computed and how you can use it to reduce technical debt of your project.
Let’s say there is one ‘if – else’ block in your entire code. Here, the cyclomatic complexity would be 2, because an if opens doors to two different blocks – one for when the condition is ‘True’ and another for when the condition is ‘False.’
Development Cost – DC
Believe it or not, when we talk about Technical Debt, the unit of development cost is “hours” and not dollars.
To calculate the development cost of a code or a project, you’ll need to determine the cost of each line of code – DC[1]. How much time, on average, did your developers invest in writing one line of code in the said project?
So, for the sake of simplicity, the DC[1] of your project code is 0.35 hours and your project has 470 lines of code.
The Development Cost of this project would be:
DC = DC[1] x Total lines of code = 0.35 hours x 470 = 164.5 hours
You can use this in the technical debt formula to calculate & hence reduce Technical Debt of your project.
Remediation Cost – RC
Remediation Cost (RC) can be defined as the total cost of fixing the issues (Technical Debt) in your software development project and, as Development Cost, RC is also measured in “hours.”
To calculate the Remediation Cost of your project, take a metric you use to determine the complexity of your code. The idea here is to determine the time it would take for your team to fix a project’s code.
Ideally, the more complex a code block is, the more time your team will spend on fixing it. So, in a way, you could say that the greater the value of complexity metric you use, the more will be the remediation cost
Let’s say that you use cyclomatic complexity as a metric. So, your Remediation Cost will be:
RC = c x Cyclomatic Complexity (of your dev project), where c is a constant.
Now that we have all the required parameters for calculating Technical Debt, here’s the formula.
Use this formula to calculate and hence, reduce Technical Debt Ratio (TDR) of your dev project.
Technical Debt Ratio (TDR) = Remediation Cost/ Development Cost.
You can extend this formula to get a Technical Debt percentage of any development project.
Technical Debt = (TDR x 100)%
Now that we know the formula, what TD percentage is considered as an industry standard?
Ideally, you should aim to keep the Technical Debt of your dev project should be 5% or less.
Types of Technical Debt
Well, defining the types of Technical Debt can be tricky.
Experts from all around the world like to categorize Technical Debt into various types as they say fit. The idea of segregating Technical Debt into various types is to simplify the communication and addressing that goes into solving these tech debt issues.
In a nutshell, Technical Debt can be put into 4 major categories –
- Unintentional technical debt
- Software entropy/ Bit Rot
- Unavoidable technical debt
- Strategic/ Intentional technical debt
Let’s dive deeper into these individual types to understand them better and how can you reduce these technical debts in your organization.
Unintentional/ Naive Technical Debt
Unintentional or Naive Technical Debt is caused due to unawareness of the best practices by your team. It could be anything from UI/UX design, Development, or even testing.
This type of Technical Debt is usually seen in software developed by inexperienced teams writing just bad code. It could be caused due to reasons like in-efficient/poor practices, poor inter-team communications, rollout issues, etc.
You can easily reduce this technical debt easily by hiring experienced developers in the first place.
Software Entropy/ Bit Rot
Software Entropy or Bit Rot is used to describe the obvious Tech Debt in an aging software. With growing demand and users, the development team has to choose between two options – release new features or address tech debt and code complexity of their earlier code.
Given the volatility of the market, companies go with the former option much more than the latter one. With every release of new features of any software system, technical debt increases along with accumulated interest.
Besides, legacy software systems also have rotten code that is just sitting there, doing nothing other than increasing the code complexity of the entire software.
This, among other types of tech debt, is known as Software Entropy.
This kind of tech debt is unavoidable in most circumstances. Here are some scenarios that fall under this category.
- Did you introduce new features in the middle of software development?
- Are you and your development team on different pages regarding the scope of your software?
- Has the technology used in your software significantly changed since you released your software and thus, rendering it obsolete?
- Has the scope of your software changed a lot during the development?
- Are new features being ‘adjusted’ in the existing design of your software?
Design debts, dev debt, or any other kinds of technical debt can fall into this category.
Strategic/ Intentional Technical Debt
Are you, as a, overlooking code complexity or Technical Debt for:
- Faster time to market?
- Customer satisfaction?
- Reduced overheads?
If your answer to these questions is ‘yes,’ your software’s tech debt falls under this category. This type of Technical Debt is avoidable but the team or the product owner decides to let it be for larger short-term benefits.
Popular Technical Debt Comparisons/Analogies
There are many comparisons that experts have used to simplify the concept and to understand how to reduce technical debt. In this section, I am going to cover the top technical debt comparisons.
Technical Debt vs Financial Debt
Financial Debt helps you reach/achieve your goals faster. Technical Debt is no different. Ignoring Technical Debt helps you deliver your software faster, keep your product competitive, and satisfy your users (with new features).
In the words of Steve McConnell himself – ‘let’s say that I am currently in the process of financing my house right now, with an interest rate of 3.5%. At this rate, I don’t think I care if I ever pay back my interest.’
‘If the rate was at 12%, then I would care more as the interest would be onerous. I think the same analogy applies for software technical debt.’
If the penalty (technical debt) you are incurring on your development project is small/negligible as compared to the greater good (customer satisfaction, in most cases) that it might make more sense to let it be.
On the other hand, if the debt in your project becomes apparent and you end up spending more resources because of it, it would perfect sense to reduce technical debt as soon as possible.
So, yes. You guessed it right! Technical Debt can be ‘good’ as well.
Technical Debt is Like A Game of Tetris
This is a particularly interesting analogy. As far as my research goes, this analogy was first seen on Colin O’Dell’s blog.
So here it goes.
When you start playing Tetris, you get an empty slate. But the thing that makes this game so important is how mindfully/strategically you place your blocks. If you don’t keep in mind the impact of a randomly-placed block on your game, it keeps getting harder.
Just like the game of Tetris, you get an empty slate at the beginning of a project. If you keep your codebase’s structure clean and manageable (keeping in mind the bigger picture), the technical debt of your dev project will negligible/small without any extra efforts.
On the other hand, if your team just keeps piling up code blocks without much reflection, technical debt and hence your dev team’s journey will become harder as you move further in the software development cycle.
Approaching Technical Debt: How to Reduce It?
By now, you know the basics, the terminologies, and different types of technical debt. The million-dollar question is – how do you approach technical debt, either to reduce it or to address it right from the beginning of your development process?
The ideal way to go about reducing the tech debt is to acknowledge & address it right from the beginning. And when I say “at the beginning,” I mean at the concept stage, even before the concept of “code quality” comes into the picture.
Scenario 1: You haven’t started developing your software yet.
Keep the conversation about tech debt alive at all stages and departments of your product development. Here are a few good practices to minimize technical debt if you are just entering the product development life cycle.
- A good UX/ technical architecture is the right place to start if you aim to limit your software’s Technical Debt.
- Evaluate your users’ needs. Do a thorough research of available, trending development technologies that you can use in your software.
- When defining (design/developing) the architecture of your product, Abstraction and Modular Programming could potentially be your biggest weapons against Technical Debt.
Scenario 2: Your product has entered the development phase.
If you follow the ‘traditional’ development process, your team probably lives by the phrase – “If it ain’t broke, don’t fix it.” Add “as per the current requirements/needs” to this phrase, you probably have created the source that’s responsible for 90% of the future technical debt of your product!
Having said that, the only thing you can do to reduce technical debt once the product has entered the development phase is – Refactoring.
Here’s the thing. Most developers or project managers get involved in software development once it’s designed.
But as I mentioned earlier, the ideal point to start if you want to reduce technical debt is during the design phase. This phase plays a significant role in defining the technical architecture of your software and hence, its technical debt.
So, what is refactoring and how can it be used to reduce technical debt?
Refactoring basically means changing the internal structure of a codebase without changing its external functionalities. It could be as simple as renaming folders and images to clearly depict their purpose/function.
The motive behind refactoring is to make the entire codebase of software development as maintainable & efficient as possible. This will improve future scalability while enhancing readability and making QA/debugging process much easier.
Over to You!
A significant part of technical debt can be reduced by –
- Following clean software development methodologies, and
- Setting up a highly experienced development team.
Resourcifi is an award-winning Staff Augmentation company with 10+ years of experience in the development industry. Hire web & mobile app developers to get future-ready, scalable digital solutions for your business!
What are you doing to reduce technical debt of your development projects. Let me know in the comments below!
