Strategies for Measuring and Prioritizing Technical Debt in Online Applications
When you’re putting in a new raised garden bed, you know you should first meticulously remove all the weeds. Then, lay down some cardboard to block weed seeds from sprouting, and finally rebuild the planting bed with suitable soil. But what if you’ve already bought the plants, it’s Sunday afternoon, and you just want to get them in the ground before it gets dark? Can’t you just make this a “future you” problem and deal with the weeds when they come up?
Just like those weeds that eventually choke your garden, the shortcuts you take to launch quickly can strangle your platform’s growth and your budget if left unaddressed. Yes, there are compelling reasons to take on technical debt when facing tight deadlines or budget constraints. But what seemed like a smart shortcut then might be costing you far more than the time you saved. Let’s look at the main kinds of tech debt you’ll encounter and ways to quantify and track it.
Six Types of Technical Debt Threatening Your Platform
- Bad code: This was the original meaning of technical debt. Whether due to inexperienced developers, ambiguous requirements, scope creep, or simply time pressure, the first iterations of a codebase are often riddled with problems. This might look like redundancy, hard-coded values or business logic that could change, clumsy procedural logic, or any number of problematic technical decisions.
- Deprecated code: Even good code ages quickly like an old smart phone. The language or framework the code was written in evolves, and older versions eventually stop receiving security updates.
- External dependencies: Modern software development almost always involves integrating a numerous software libraries, web services, and outside applications or infrastructure. These can age, and become insecure or non-performant.
- Unused functionality: We don’t always get it right in the design phase. There are often big chunks of functionality that seemed crucial at first, but never ended up being used— either the audience didn’t find them useful, or the feature never got implemented in the first place. With a CMS like Drupal or WordPress, there can be dozens of installed modules or plugins that aren’t fulfilling any essential purpose but are still potential sources of errors or gateways to intrusion attempts.
- Documentation: It’s very common to iteratively change and add to a codebase and fail to update the documentation to reflect those changes. This can be code comments/DocBlocks, formal definitions like OpenAPI or DBML schemas, or user-facing documentation about how to use the product. As the documentation and the codebase drift further apart, it becomes increasingly challenging for new developers or users to learn the application and maintain or change it.
- Content: This is far from the original meaning of technical debt, but it can still be a significant liability for any online application—, especially one with a large library of content that has evolved over time. Links or embedded images no longer work, content becomes dated or inaccurate, or as accessibility standards change, may no longer meet legal requirements. There’s likely content no one even remembers is there, and some of it may be an organizational liability.
How to Audit and Measure Technical Debt
It can be difficult to know how deep “in the hole” your application is, even for experienced developers. The tendency of modern networked applications to consume various libraries, web services, and infrastructure offerings only makes this more challenging by offering multiple areas where debt can hide.
Scanning for code complexity and “smell”: One lower-effort approach to assessing the scope of bad code issues involves using scanning tools like SonarQube. Often used as part of a continuous integration pipeline to help improve new code, these utilities can also run against an existing codebase to quantify the issues already present in the project. They report problems like overly deep loops, methods with too many parameters or unused parameters, and unexplained numerical constants as “code smells.” These aren’t necessarily problems, but they tend to be associated with complex code that’s hard to parse and harder to reuse.
Documentation debt: Documentation that isn’t synchronous with the codebase can be worse than useless. Focus on initially measuring critical paths, like API specifications and tooling necessary to get the site working. Many IDEs have tools for measuring how many functions lack comments, and some frameworks have their own “linting” tools (e.g., Drupal’s Coder module, or the JSLint library). These tools specifically complain about failure to document which hook a given function implements or what form the parameters of a function must take. You can also use higher-level audit strategies like measuring the time to onboard new developers or administrators to the codebase.
Dependency management tools: Most modern web frameworks use at least one, and often several, package management tools like PHP’s composer, Python’s pip, or Node’s npm. These package managers generally include audit functions that can generate lists of external dependencies, and notify you of any that are deprecated.
This is helpful for libraries or other local dependencies, but what about those hosted external web services your application consumes? While it’s a more manual process, it’s vital to conduct a full inventory of the services being used. Look in the codebase for API keys, domain patterns, and other indicators. Even looking at firewall logs and the browser console can often help you discover these dependencies. Once you have this list, it’s straightforward to go through it and verify that the services are still functional and you’re using modern releases.
Quantifying business outcomes: Depending on your project management methodology, you may already be tracking measures like feature delivery time, overall velocity, and defect escape rate—the number of bugs that make it to production. These can indirectly correlate to growing technical debt, although it’s important to avoid assuming that debt is the sole cause of changes to these metrics.
Key Metrics for Tracking Technical Debt
Technical debt ratio: The amount of time required to remediate the issues in a project, vs. the amount of time required to rebuild the project using modern methods and best practices. As this ratio approaches 1:1, rebuilding can be more cost-effective than fixing what you have. (Note that we’re comparing the remediation time to an estimated rebuild time, rather than to the original development time.)
Issue density: Track the concentration of code quality problems in a codebase by measuring against some known quantity, such as “code smells per 1,000 lines of code” or “critical issues per file.” This helps you identify which components of your application need the most attention and resources.
Maintainability grade or remediation effort: Assess the relative effort involved in maintaining code or in fixing the code quality issues. You can measure this for the whole project, or, more usefully, for each component of the project, such as the authentication system or document management. This helps prioritize where to invest your development resources.
Ratio of custom to community-maintained code: When working in open-source frameworks, particularly those with active community support, there is a presumption that open source-code comes with less liability. As long as developers stay current on software updates, you can be confident that others have scrutinized the open-source code and that downstream security advisories have been considered and implemented.
Weighting: As you’re considering the technical debt embodied in each component of your application, you’ll want to factor in some other data points, beyond just the time and effort to remediate. These might include:
- Risk factor: How consequential will a failure be, especially if the component involves financial transactions or personally identifiable information?
- Business criticality: Is this a peripheral component or one tied to vital business practices (e.g., a user profile picture vs. the subscription renewal function)?
- Strategic alignment: How closely does this component relate to or support strategic technical initiatives— for example, if your organization is promising AI integration to customers?
Making Technical Debt Work for You
Like financial debt, some types of technical debt are strategic investments, while others can cripple your growth. The key is knowing which is which. Before your organization makes critical product strategy decisions, you need a clear assessment of your technical debt’s sources, scope, and true cost. Without this roadmap, those quick fixes can continue to strangle your platform’s potential.
Technical debt doesn’t have to derail your growth plans. We’ve helped organizations large and small navigate these challenges for nearly three decades. Our approach starts with a clear assessment of your technical debt’s sources, scope, and true cost—giving you the roadmap you need to make informed product strategy decisions. Whether you’re facing renewal rate challenges, struggling with feature velocity, or planning a major platform evolution, understanding your technical debt is the first step toward sustainable growth.
Curious about where your platform stands? Let’s talk about what a technical debt assessment could reveal for your organization.