Use Case
Manage technical debt systematically across four stages: automated detection, business - impact triage, prioritization, and verification that fixes actually worked.
At Salesken, we had a 'tech debt' label in Jira with 200+ tickets. When our board asked how much technical debt we had, I couldn't give them a number. That experience taught me that unmeasured debt is invisible debt.
Most engineering organizations treat technical debt like a junk drawer. Things accumulate. Occasionally someone opens the drawer and says, "We should really clean this up." Then they close the drawer and move on. A few items make it to a Jira epic labeled "Tech Debt" that sits in the backlog, slowly gathering subtasks and comments until nobody remembers why it mattered.
The companies that actually ship fast are not the ones with the least debt. They're the ones with the best debt management systems. They detect debt early. They triage it against roadmap impact. They prioritize by business consequence, not technical severity. They remediate systematically. They verify that the fix actually stuck.
Glue makes this lifecycle systematic instead of ad-hoc.
Most teams have no systematic way to detect technical debt at all. They find it by accident. An engineer refactoring discovers that a component is more complex than it should be. Someone tries to add a feature and realizes the auth system is brittle. A performance incident reveals that a particular module is behaving poorly under load. These are all real debt signals, but they're reactive. You're finding the problems after they've already affected your velocity.
When debt is found, the next problem is triage. Not all debt is equal. Some debt blocks shipping. Some is just annoying. Some is structural ( - it will get worse over time). Some is trapped in dependencies and can't be fixed without fixing three other things first. Without triage, you can't prioritize.
Then comes prioritization. Most teams prioritize debt by technical severity: "This code is really complex, we should refactor it." But business impact is different from technical severity. A moderately complex module that blocks three teams from shipping is higher priority than a highly complex module that nobody touches. The financial impact is different.
Finally, remediation. You fix the code. You write a PR. It gets reviewed. You deploy. Done.
Except not done. In many cases, the structural problem that caused the debt in the first place is still there. You refactored the code, but you didn't refactor the system that created the pressure that led to the debt. Six months later, the "fixed" component is complex again.
Verification is the step that almost never happens. You assume that because the ticket is closed, the problem is solved. You rarely go back and ask: did this refactor actually improve system health? Or did we just move the complexity somewhere else?
Some teams try to prevent debt by being strict about code review. "We will not accept complex code." This works for small teams with strong technical culture. It fails the moment you scale, because code quality is subjective and reviewers get tired. You can't code-review your way out of debt.
Others try architectural principles. "No circular dependencies. No large modules. Every component has a single responsibility." Good principles, but without enforcement, they decay. Without data, it's hard to know if you're actually following them.
Some use automated tools that scan code and flag complexity. Cyclomatic complexity tools, dependency graph analyzers, code duplication detectors. These are useful. But they generate a lot of noise. They flag problems without understanding impact. A complex module that everybody touches is much more painful than a complex module that one team owns and understands. The tools don't know the difference.
The deepest problem: most approaches treat technical debt as a technical problem. It's actually a product and organization problem. Debt accumulates because of business pressures. You shipped fast. You cut corners. You prioritized feature delivery over architecture. This is a legitimate trade-off. The problem is not that you made the trade-off. The problem is not knowing when the cost of the trade-off exceeds the benefit.
Glue transforms the technical debt lifecycle into a data-driven system with four stages: detection, triage, prioritization, and verification.
Glue continuously analyzes your codebase and tracks structural metrics: complexity, coupling, code duplication, rate of change, number of owners per module.
When metrics cross thresholds, Glue flags them. Not as "this code is bad." As "this area is deteriorating and should be triaged."
An engineer asks Glue: "Show me all areas of the codebase where complexity has increased more than 20% in the past two months."
Glue shows: the user management module has grown from a complexity score of 7 to 8.5. The payment processing module has grown from 5 to 7. The reporting dashboard has grown from 6 to 9.
These are debt signals. The user management module is approaching the threshold where it becomes difficult to modify. The payment processing module just crossed into difficult territory. The reporting dashboard is now approaching the "should probably be split into separate modules" zone.
But here's the key: Glue isn't making a judgment about whether this debt is "bad." It's surfacing a signal that structural health is changing. The team decides what to do with the signal.
Not all high-complexity modules are problems. A complex module that hasn't been touched in six months is not a priority. A complex module that five teams need to integrate with is.
The team asks Glue: "Which complex areas of the codebase are blocking the most incoming work?"
Glue cross-references complexity with change frequency and the number of incoming feature requests that touch that code. It shows: the auth system has moderate complexity but is touched by 80% of your roadmap work. The admin panel has high complexity but is only touched by the admin team. The data pipeline is very complex and is touched by three different teams working on different features.
Now triage is clear. The auth system, despite not being the most complex, should be a priority because it's a bottleneck. The data pipeline is a concern but not immediately urgent because only one team is currently impacted.
You've triaged the problems. Now you need to score them so you can decide what to actually work on.
This is where most approaches fail. They score by technical metrics: "This module has a cyclomatic complexity of 80, this one has 45, so fix the first one." But business impact is different.
Glue lets you prioritize by impact. The team asks: "For each of the complex modules we identified, how many teams are dependent on it, how many feature requests would be unblocked if we fixed it, and how much time is currently spent in maintenance versus building on top of it?"
Glue shows: the auth system blocks three major roadmap initiatives. Teams spend 20 hours a month on auth maintenance that would be eliminated if the system were more maintainable. The data pipeline blocks two initiatives but the maintenance load is lower because it's more stable. The admin panel is mostly maintenance ( - it's where bugs accumulate) but it doesn't block roadmap work.
Score them:
Now your priority is clear. Not because the auth system is technically hardest, but because fixing it has the highest business impact.
Once you've prioritized, you need to fix the problem. This is where codebase context matters.
The team decides to refactor the auth system. Before they start, they ask Glue: "What's the actual scope of the auth system? What modules depend on it? Where is it changing most rapidly?"
Glue shows: the auth module has interfaces to the user service, the session manager, the permission checker, and the API gateway. There are seventeen places in the codebase that directly import from auth. It's being touched by different teams for different reasons: the platform team for OAuth integration, the security team for 2FA, the growth team for signup flow optimization.
The refactoring team now knows: they can't just refactor auth in isolation. They need to consider the downstream impacts. They need to coordinate with the teams using it. They can't assume they understand all the use cases.
This prevents the most common refactoring failure: you fix the module in isolation and break something you didn't know was depending on it. With this context, you can refactor with confidence.
The refactoring is done. The PR is merged. The complexity metrics have improved. Does this actually solve the problem?
Glue lets you verify. You ask: "Post-refactoring, what changed in the auth system? Is the structural issue resolved, or did we move the complexity somewhere else?"
You look at the new metrics:
But here's the deeper verification: you also look at the downstream effects. Did the teams depending on auth actually spend less time on maintenance? Did the refactoring enable the blocked roadmap work?
If the answer is yes, the debt remediation was successful. If the answer is no ( - teams are still struggling with auth integration), then the refactoring fixed the code but not the underlying problem. Maybe auth needed better documentation. Maybe it needed better interfaces. Maybe the upstream teams needed to change how they use it.
This feedback loop is critical. It tells you whether your debt reduction strategy is actually working or if you're just chasing technical metrics.
Teams that implement systematic technical debt management see three outcomes:
First, they ship faster. Debt that blocks roadmap work gets fixed systematically. You don't have implicit technical constraints on your feature roadmap anymore. Features take longer than they should to implement because you're fighting bad code, and you fix the bad code once you notice it. With systematic management, you fix the bad code before it becomes a bottleneck.
Second, their architecture stays coherent. When you're verifying that refactors actually improved things, you're forcing architectural thinking. You're not just writing code, you're maintaining system health. Over time, this compounds. Your codebase doesn't drift as far from its original architecture.
Third, they build more accurate product roadmaps. Instead of discovering constraints during feature work ("We can't ship this feature because the auth system is fragile"), you discover them during planning. You know which parts of the codebase are debt time-bombs. You can either avoid them or plan to fix them before depending on them.
Technical debt management is not a separate activity. It's a product activity. Better debt management means better product velocity.
Q: How do we decide which metrics matter? Should we optimize for complexity, coupling, duplication, or change frequency?
A: Don't optimize for any single metric. Use them all. Glue shows you all of them. The pattern that matters is when they correlate. High complexity plus high coupling plus high change frequency plus multiple owners = serious problem. High complexity alone = might not matter. Use the metrics as flags, not scorecard.
Q: What if teams disagree on whether debt should be fixed? Engineering thinks the auth system is critical, product thinks we should build features.
A: This is the right question to argue about. Glue gives you the data to argue clearly. Glue says: "Fixing auth would unblock three roadmap items and reduce maintenance overhead by 20 hours per month." Now you have a real trade-off. Is three items worth 20 engineering-weeks of refactoring? Different organizations will have different answers. But at least the decision is informed.
Q: Can we use this to argue for not doing tech debt work?
A: Yes, absolutely. If Glue shows that fixing a piece of debt only benefits one team and the business impact is low, then the argument for fixing it is weak. The value of this system is that you're allocating scarce engineering capacity based on impact, not on "engineering thinks this should be fixed."
Q: What about legacy code that's not changing? Should we ever refactor it?
A: Almost never. If a module is complex but hasn't been touched in two years and doesn't block anything, refactoring it is wasting capacity. Glue will show you this ( - low change frequency, low impact). Sometimes the best debt management is knowing when not to pay it down.
Q: How do we prevent new debt from accumulating while we're fixing old debt?
A: This is an organization question, not a Glue question. Glue detects debt and prioritizes it. But if your development culture keeps creating debt at the same rate you're fixing it, you'll never get ahead. You need to understand why debt is accumulating. Usually it's schedule pressure. If you're shipping fast and cutting corners, that's fine ( - that's often the right trade-off). But you need to make it explicit and plan to remediate it. Glue makes it easier to track and plan.
Q: Should we put a "no new debt" rule in code review?
A: No. Code review is the wrong place to enforce this. Code review is for catching bugs. Debt is a system-level decision, not a code-level decision. Use Glue to track debt accumulation, then use planning and prioritization processes to decide when to pay it down. A code reviewer saying "this code is too complex, rewrite it" without understanding the business context is not helpful.
Keep reading
Related resources
