Last updated on November 28th, 2022
If the world was a utopian place, every software project would finish on time and within the estimated budget. It would also be a place where development teams could push out additional features and test everything twice over before the product release. The real world, unfortunately, operates quite differently. In this world, development work can be fraught with issues and hurdles. Timelines are tight and compromises must be made. And technical debt results.
Clearly, technical debt is not necessarily bad. Just like how some financial debt can help you lead a better life, think buying a house, owning that car or taking that exotic vacation. But what happens if you don’t measure your financial debt? What if your debt is higher than your income? You miss your payments; your financial credibility is impacted. And rather than improve your life, things get worse.
It’s the same with technical debt. It is the necessary evil that software development teams have to live with to meet the needs of today’s dynamic market. These teams have to match the speed of innovation and roll out software products fast while navigating a treacherous landscape of legacy systems, bugs, and errors. Some technical debt becomes inevitable here.
However, it is important to be prudent about incurring technical debt because accumulated debt can severely impede your growth.
What is technical debt?
I like the definition of technical debt by The Software Engineering Institute at Carnegie Mellon University. They say technical debt “conceptualizes the trade-off between the short-term benefit of rapid delivery and long-term value.”
While we might all want to develop perfectly designed software with clean, well-designed code that can be iterated easily for future innovation, reality intervenes. There must be a trade-off between perfect products and pressing timelines. When developers get caught in situations where they might need to add new functionalities they often choose to get the functionality going even while knowing that ignoring certain aspects can impact future development. You might indulge in less-than-optimal coding practices to deliver software capabilities faster. So, you do what needs to be done now, leaving the cleaning up for later.
The thing is, this cleaning up can pile up and later, it might get incredibly hard to implement change. It’s like a teenager cleaning up by hiding a huge mess under the bed. It’s all clean but nothing is in its place and everything is hard to find.
How do you know if you have accumulated technical debt?
There are many kinds of technical debt. There’s planned technical debt, where you make an informed decision to take on this debt to meet a deadline. Then there’s unintentional technical debt – debt that you accumulate due to poor development practices. Finally, there’s the unavoidable technical debt that accumulates over time due to business, or technological changes that make old code obsolete.
You know you have technical debt when:
- Your code presents problems that are likely to impact overall performance
- Your development decisions are consistently hasty
- Your user experience continues to be clunky
- Audits show that most of the performance-related errors are coming from within the system
- Levels of complexity increase significantly when technologies overlap
But do you know how bad your technical debt is?
While financial debt can be easy to track, it can be tough to measure technical debt. Calculating technical debt can be a mammoth task, especially when done manually. Going into all the code, identifying all issues and setting time and effort estimates to resolve those can become a herculean effort, and almost always, a thankless one.
Of course, technology can come to the rescue. Today you have a bundle of tools that perform a static analysis of code. Using such tools you can get the ratio of technical debt to the volume of code. Some tools give you a direct estimate of the volume of technical debt that you have incurred. But I have noticed that mostly what you get is a number – where that number comes from, what can you do with it, how good or bad your technical debt is, how must you go about paying off your debt, what you need to do next, not much is clearly outlined. Current tools lack the ability to say what a good or bad score means. Consequently, they do not clarify what that score could mean in terms of the product and product development.
Fixing technical debt costs money and man-hours. Leaving technical debt inside the code is not an option as uncorrected technical debt leads to more technical debt making it harder to fix. Addressing technical debt is a cost but addressing it sooner is better than trying to manage the task later.
Refactoring code and reviewing the software architecture helps to reduce technical debt as then you don’t end up with code that lacks modularity or with duplicate code. Proactively updating the software to newest versions of the databases, frameworks, application servers, etc., helps. Identifying and prioritizing issues and having a laser focus on testing also contribute towards reducing technical debt.
I believe that while these tools and technologies do help us to some extent with technical debt, the first thing to do is fix development practices so that we accumulate less debt. With good development practices in place, you’ll only accumulate as much debt as you can manage without impacting the quality of your software. Isn’t that the most logical thing to do?
