Identifying Tech Debt Worth Fixing
Identifying Tech Debt Worth Fixing
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.
According to a survey from McKinsey, 60% of Chief Information Officers believe that their tech debt has risen significantly over the past three years. They also estimate that tech debt accounts for 20-40% of their entire tech estate—the equivalent of hundreds of millions of dollars.
Tech debt is so common, and is accrued so quickly because development teams work under time constraints, which incentivizes teams to take shortcuts rather than taking the time to develop a more comprehensive solution. Also, many teams are understaffed, so there simply aren’t enough people to meet the tasks at hand.
Teams often wrestle with paying off tech debt in their code to make the product more usable and stable vs. adding new features that can help benefit the company’s bottom line.
But in a development world where there is typically more debt than time to pay it off, how can teams determine which areas to prioritize? Allow us to break things down.
Assessing different types of tech debt
End-user & business impact
Engineering 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.
Interested in learning more about tech debt and how to tackle it? Watch CodeLogic’s video, How to Identify Tech Debt in Your Code.