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.

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.

Developers shouldn’t choose between quality & speed. Instantly expose high risk software dependencies and prevent breaking changes.

Assessing different types of tech debt

Before deciding which specific tech debt should be addressed, it’s important to assess how the users, business and engineering team will be impacted.

End-user & business impact

First, it’s key to identify tech debt that can negatively impact end-users and, therefore, impact the business. This scenario occurs when tech debt hinders a user’s ability to complete an online purchase, access a provider’s content, or sign-up for a service. For example, does the tech debt impose maintenance that will render the service unavailable to users during those times? Moreover, there may be convoluted areas of the code that, when modified, often result in other end-user-impacting consequences. While tech debt doesn’t always impact the end-user, if it affects sales or creates a poor user experience, it might be worth addressing sooner. It’s important to ask, “How will addressing this tech debt affect the end-user?” and “Will the business be negatively impacted while it’s being addressed?”

Engineering impact

Next, it’s important to assess how tech debt impacts engineering. What would happen if the team doesn’t fix the tech debt immediately? Often, when tech debt is left unchecked, it slows down the engineering team’s ability to add new features. It creates increasing code complexity and application risk and makes the codebase more difficult to change. Documentation is often used to better understand code complexity, but without up-to-date documentation, engineering teams are left to rely on the tribal knowledge of senior developers and an incomplete view of their code connections. When team members leave, they take their knowledge with them and those left behind must decipher the complex code, leading to increased risk when they finally address the tech debt. This is a common cycle. A rushed team incurs tech debt to deliver more features. That debt reduces the team’s natural throughput as they pay interest on the debt, further crushing the team and encouraging them to take on more tech debt. Eventually, it becomes nearly impossible to improve the application, and the difficult decision to abandon it and rewrite is made – the tech debt equivalent of bankruptcy. When development teams do fix their tech debt immediately, engineering moves faster, debugging is easier, and product performance improves. Because the team can deliver changes more quickly and safely, the business can better respond to their changing needs.

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.

Explore the CodeLogic Sandbox.