Identifying Tech Debt Worth Fixing
Identifying Tech Debt Worth Fixing
What is technical debt?
Developers are all too familiar with tech debt. The topic is often the focal point of dev team meetings and organizations’ strategies to improve their offerings. The term refers to the consequence of implementing a solution that saves time and money in the short term, but results in more fixes in the long term. The additional ongoing work imposed by taking a shortcut can be thought of as paying interest on a debt. Only by reworking the solution fully, can the debt be paid off and the burden eliminated.
Assessing different types of tech debt
End-user & business impact
Recognize business needs vs technical needs
Product management and upper management are more likely to fix tech debt when there is a quantifiable impact on the business. For example, a drop in customer conversions and revenue due to a slow loading website or glitchy cart experience. For these types of business issues, there’s a clear-cut view that if tech debt results in lost revenue or customers, fixing it needs to be a priority. However, the connection between tech debt and lost revenue is rarely made because it’s not easy to quantify.
Most teams lack tangible data necessary to illustrate the complexity of tech debt and its impact on the business. Moreover, engineering teams are often more concerned with the complexity of the code and how it impacts their day-to-day work. Often slowed workflows aren’t enough reason to prioritize fixing tech debt. If the business decides to address this type of tech debt, sufficient time will have to be dedicated at the expense of adding new features that could improve the customer experience and grow the business.
Use dependency mapping to identify the tech debt worth fixing
Rather than having to navigate the friction between product and engineering teams, organizations could use tangible data to strategize tech debt. Dependency mapping gives developers quantitative data to highlight the impact of tech debt, allowing them to make informed decisions about the risk of tech debt to both the product and the business.
A simple way to prioritize technical debt objectively is to ask two questions:
- What code is problematic?
- Which problematic code is widely relied on?
Problematic code (typically long, complex methods and classes) may be tolerable if it’s isolated in an obscure corner of the system. If instead, many items call it, the likelihood of a developer breaking something skyrockets.
An effective dependency mapping platform reveals key application data points to surface its complexity. For example, CodeLogic’s dashboard is broken down into four categories:
- Inventory of classes, methods, database tables, columns, and foreign keys
- Code complexity score
- Trend line
- Class and method analysis
The CodeLogic dashboard answers the two questions above by surfacing the 50 methods or classes that score the highest in complexity, visually represented with various sized bubbles based on the number of references called by those methods or classes. By using application dependency intelligence to help answer the question of its complexity, prioritizing what to address is made easier. Teams using other tools for detecting technical debt can also look up methods in CodeLogic to see exactly where they are referenced across their application landscape, to optimize tech debt prioritization and strategize how to deal with it.
The more you can identify and correlate tech debt with potential business impact, the easier you can align organizational priorities and reduce risk to your applications and the business.