If you've been shipping code for more than a year, you have technical debt. The question isn't whether it exists — it's whether you can see it, measure it, and have a plan to address it.
Most teams feel the drag: slow deployments, fragile tests, the growing anxiety around "what breaks if we touch this module?" But they can't articulate specifically what the debt is.
After a decade in codebases of all sizes, I've found the damage doesn't come from abstract debt. It comes from concrete patterns that recur across teams. These seven patterns are the ones that actually slow you down.
1. Dependency Tangling
Modules that should be independent have become tightly coupled through ad-hoc integration. You can't change the API gateway without touching the database layer. Updating the auth service means modifying three payment modules.
How to spot it: Try to extract a module for reuse or testing. Discover it imports from 8+ other modules, and those modules import back. The dependency graph isn't a tree — it's a mesh.
What it costs: Every change becomes risky. Testing becomes expensive. Onboarding slows because nobody can understand code in isolation.
Fix: Map the actual dependency graph. Make coupling explicit with defined APIs. Introduce a layering strategy: presentation → business logic → infrastructure, nothing flowing backward.
2. God Objects
A single class or module that knows too much and does too much. The UserService that handles authentication, authorization, profile management, notification preferences, AND billing.
How to spot it: The class has dozens of public methods with nothing in common. The file is 2000+ lines. Pull requests to this file are always massive and touch unrelated logic.
What it costs: Impossible to test. False bottlenecks (everyone waiting for everyone else's changes). One misunderstood invariant breaks half the application.
Fix: Break apart by responsibility. UserService → AuthService + AuthorizationPolicy + ProfileManager. Start with the smallest responsibility you can separate cleanly.
3. Implicit Contracts
Interfaces that work only because of undocumented assumptions about call order, data format, or environment state.
How to spot it: Something works in production but fails in tests. The difference is some invisible precondition. Engineers regularly get surprised by how a system behaves.
What it costs: Systems become fragile. Debugging takes forever. Refactoring becomes dangerous because you don't know what assumptions the code depends on.
Fix: Make contracts explicit. Add assertions. Document sequences. Use type systems to encode invariants. If initialization order matters, enforce it in code.
4. Test Debt
Production code that can't be tested without heroic mocking effort.
How to spot it: Test files are longer than the code they test, and half the test is setup. You avoid writing tests for certain modules because "it's too complicated."
What it costs: You lose confidence in changes. Tests don't catch regressions because they're brittle. You ship bugs because you only test through manual clicks.
Fix: Invert dependencies. Push external connections to the edges. Use dependency injection. Start small — make your next module testable.
5. Configuration Sprawl
Environment-specific logic scattered across the codebase. If-statements checking env === "production". Different S3 bucket names hardcoded in three different modules.
How to spot it: Deployment to a new environment requires code changes. Environment-specific bugs can't be reproduced locally. Same config defined in three places with different values.
What it costs: Error-prone deployments. Can't safely test without running in the actual environment. Adding a new environment requires changes throughout the codebase.
Fix: Centralize configuration. Read environment variables once, at startup. Feature flags in a single source of truth. Code should be environment-agnostic.
6. Parallel Implementations
Multiple implementations of the same logic existing simultaneously because nobody knew (or trusted) the existing one.
How to spot it: Search for "date formatting" and find five different utility files. Three different HTTP client wrappers. Two implementations of the same business rule in different services.
What it costs: Bug fixes need to be applied in multiple places (and they never are). Behavior becomes inconsistent. The codebase grows without adding value.
Fix: Search before writing. Use codebase intelligence to discover existing implementations. Consolidate gradually. Don't create new utilities without checking what already exists.
7. Knowledge Concentration
When critical system understanding lives in one person's head. Not a code pattern, but it's the most expensive debt of all.
How to spot it: "Ask Marcus, he built that." PRs for a critical service always assigned to the same reviewer. When that person is on vacation, changes to their service wait.
What it costs: That person becomes a bottleneck. When they leave, the team loses months of productivity. The bus factor for the system is 1.
Fix: Pair programming rotations. Require multi-person code review for critical systems. Document architectural decisions (ADRs). Track knowledge silos explicitly.
How to Prioritize
Not all debt is equal. Prioritize by:
- Blast radius — How many things break when this area changes?
- Change frequency — How often does this area need to change?
- Team impact — How many engineers are slowed by this?
Debt in code that changes weekly and affects 10 engineers is more urgent than debt in code that hasn't been touched in a year.
The mistake most teams make is treating tech debt as one amorphous backlog item. Break it into specific patterns. Measure each one. Fix the ones that cost the most.
Originally published on getglueapp.com/blog/tech-debt-patterns
Glue helps you identify these patterns automatically — mapping dependency tangles, knowledge concentration, and code health across your entire codebase.
Top comments (0)