Debt grows

Debt grows is the default state of software engineering in organizations that have not made debt management a deliberate practice. Every sprint adds new features; every feature ships with small shortcuts, undocumented assumptions, and quick fixes that were meant to be revisited but never are. Over time the codebase accumulates a layer of entropy that makes every subsequent change slower and riskier than it would be in a clean system.

At L1, debt growth is not tracked, not measured, and not discussed in planning. Developers know it exists because they feel it every time they touch certain files - the ones where a simple change triggers a cascade of side effects, where tests are absent or unreliable, where the data model long since diverged from the domain model it was meant to represent. The knowledge of where the debt lives is tribal, held by whoever has been around longest.

The growth is compounding. A codebase with high debt is slower to change, which means features take longer, which means there is less time for cleanup, which means debt grows faster. Teams in this state often describe a feeling of running on a treadmill: working harder each quarter to deliver the same amount of value as the codebase resists them more and more.

The absence of AI tooling makes this worse. Without automated refactoring, every debt-reduction effort requires a developer to manually touch code - competing directly with feature work for the same finite engineering hours. In an organization without AI tools, the math almost always favors features over cleanup, and debt wins.

• Velocity erosion - Debt acts as friction on every development task; teams with high debt consistently deliver features slower than their counterparts on clean codebases, even with equivalent headcount
• Onboarding cost - New engineers spend weeks or months learning the local workarounds, undocumented patterns, and danger zones before they can be productive
• Bug multiplication - High-debt codebases have more bugs per line of change because the implicit assumptions are not obvious and the test coverage is sparse
• Morale drain - Developers who spend most of their time fighting the codebase rather than solving problems become disengaged; high debt correlates with higher attrition on engineering teams
• Strategic lock-in - The longer debt grows unchecked, the more expensive any future modernization becomes, effectively locking the organization into outdated technology stacks

1. Name the problem explicitly - Introduce "tech debt" as a first-class concept in team conversations. If it has no name, it has no budget and no plan. Start by acknowledging that debt exists and that it has a cost.
2. Do a one-hour debt audit - Have the team spend one hour listing the five most painful areas of the codebase. No tooling needed. Just answers to: "Where do you dread making changes?" This produces the first raw debt inventory.
3. Attach a cost estimate to one item - For one debt item from the audit, estimate how much slower it makes development. "This module takes 2x longer to change than a comparable clean module." Putting numbers on debt makes the business case for addressing it.
4. Reserve 10% of sprint capacity for debt - Make a policy decision that 10% of every sprint is available for debt reduction. This does not require permission to fix every item - just establishes the principle that debt is work, not a luxury.
5. Track before-and-after velocity - When a debt item is addressed, measure whether the next change to that area is faster. Even one data point starts building the evidence base that debt reduction has measurable ROI.
6. Stop adding to the debt intentionally - Establish a lightweight code review norm: "We don't accept new technical debt without a ticket to address it." This stops the bleeding before attempting to reduce the existing balance.

Treating debt as a moral failing. Teams that shame developers for creating debt create an incentive to hide it rather than surface it. Debt is the result of reasonable tradeoffs under time pressure - every mature codebase has it. The goal is to manage it, not assign blame.

Big-bang cleanup projects. "We'll fix everything in Q3" is a plan that almost never executes. Large dedicated cleanup sprints compete with feature pressure, get deprioritized, and produce partial results that are harder to maintain than the original. Incremental debt reduction is more effective than periodic cleanups.

Debt that is invisible until it breaks. If the only time debt is discussed is during a production incident, the team is operating reactively. Proactive debt audits - even informal ones - are more effective than waiting for a crisis to force the conversation.

Measuring debt in lines of code or age alone. Not all old code is debt; not all new code is clean. The relevant measure is: how much does this specific area slow us down? Debt that no one ever touches is far less costly than debt in hot paths that change every sprint.

Waiting for perfect categorization before acting. Some teams spend months trying to build a comprehensive debt register before addressing any of it. A rough list of the five most painful areas, acted on immediately, is worth more than a perfect inventory that never leads to action.