What is Tech Debt?

Tech debt (short for technical debt) is the future cost of rework that accumulates when a software team chooses a faster, lower-quality solution over a more thorough one. The term was coined by Ward Cunningham in 1992, who compared development shortcuts to financial debt: the initial loan speeds things up, but interest accrues until the debt is repaid.

Tech debt lives in every codebase. The question is whether it is intentional and tracked, or invisible and compounding.

How to Measure Tech Debt

There is no single universal formula for tech debt, but the most reliable proxy is the proportion of engineering effort spent on maintenance work: modifying or deleting code that was already written and merged. A team investing 40% of its capacity in maintenance is telling you something.

Complementary signals include sustained cycle time increases, rising rework rates, and deployment frequency declining despite stable headcount.

How Hivel measures Tech Debt

Hivel tracks tech debt through its Maintenance % metric, available on the Coding screen. Maintenance is defined as lines of code modified or deleted that were originally written more than 30 days ago. The formula:

Maintenance % = lines modified/deleted (original code > 30 days old) / total lines added or modified

The 30-day threshold is configurable. A rising Maintenance % over consecutive sprints signals accelerating tech debt. Hivel surfaces this alongside New Work % and Rework % so engineering leaders can see the investment split across three work categories, not just velocity. See the full breakdown in Understanding Rework, New Work, and Maintenance

How to validate your Tech Debt trend in Hivel

1. Open the Coding screen and set the date range to the last 3 months.

2. Check the Maintenance % tile and look for a sustained upward trend across sprints.

3. Filter by repository to identify which codebases are driving the highest maintenance load.

Why Tech Debt Matters for Engineering Teams

The danger of tech debt is not a single costly sprint. It is the compounding effect over time. Each shortcut adds to maintenance load; each maintenance-heavy sprint leaves fewer hours for new work; slower delivery raises pressure, which generates more shortcuts. The cycle feeds itself.

For engineering leaders, the real cost is capacity displacement. If 35% of engineering effort goes to maintenance, that is 35% not available for product investment. Accenture estimates tech debt costs US companies $2.41 trillion annually, much of it invisible because maintenance rarely shows up as a line item in sprint plans.

Tracking tech debt through Maintenance % lets leaders set targets, benchmark against prior quarters, and make the investment case for refactoring sprints with concrete data rather than gut feel. Platforms like Hivel surface Maintenance % alongside New Work % and cycle time so engineering leaders can see patterns, not just isolated signals.