Tech debt snowballs, then it avalanches
In personal finance, “snowball” and “avalanche” are two strategies for paying off debt. In software, they describe what happens when you don’t.
Ward Cunningham coined the term technical debt in 1992: shipping code you know isn’t quite right is like borrowing money. It gets you there faster, but you pay interest every time you work in that code afterwards. What the metaphor doesn’t capture is the shape of the damage. Technical debt rarely hurts a little, steadily. It grows quietly for a long time, and then, on one particular day, it stops everything.
The snowball
The snowball phase is easy to live with, which is what makes it dangerous. Each shortcut makes the next change slightly harder, so the next change takes a shortcut too. Nobody decides to build a mess. It accumulates one reasonable compromise at a time.
From the inside, it looks like this:
- Estimates creep. Work that used to take a day now takes three, and nobody can quite say why.
- “Don’t touch that.” Parts of the system become places people route around instead of change.
- Skipped upgrades. Framework versions fall further behind, because each upgrade is now a project.
- One person who knows. A single engineer becomes the only safe pair of hands for a critical area.
None of these stops delivery. That’s the trap. Features still ship, just a bit slower each quarter, so the cost never shows up as an event anyone has to respond to.
The avalanche
Then one day, the debt stops being optional. Usually something outside the team’s control lands on top of it: a security vulnerability in a version that’s no longer supported, a vendor end-of-life date that can’t be moved, or the one person who knew the system leaving.
On that day, the roadmap stops. No new features ship until the problem is fixed, and it has to be fixed under pressure, all at once. The work that could have been done in small pieces over a year now has to be done in weeks.
That’s the part I think every developer should respect: you don’t get to choose when the avalanche happens. You only get to choose how much snow is on the mountain when it does.
What it looks like in practice
Picture a team running a customer-facing web platform on a framework version that’s a couple of releases behind. Upgrading was first raised two years ago, but there was always something more urgent, and every quarter the upgrade got a little bigger. A few libraries were pinned to old versions. One engineer understood the build setup well enough to change it safely. Estimates for anything touching the core quietly doubled, and nobody connected the dots, because features were still shipping.
Then the vendor announces the version’s end-of-support date, and a few weeks later a security advisory lands for a dependency that can’t be patched without the upgrade. Now the upgrade isn’t a roadmap item. It’s the roadmap. Feature work stops for the best part of a quarter, and the business asks why a “simple upgrade” is taking so long.
Nothing in that story was a bad decision on its own. Each deferral was reasonable. That’s what makes it a snowball.
What to do before the avalanche
The goal isn’t zero debt. A deliberate shortcut to learn something quickly, or to hit a date that genuinely matters, is fine if you plan to pay it back. The goal is to keep the snowball small enough that an avalanche day is survivable.
- Make it visible. Keep a simple debt register. Debt that’s written down can be prioritised. Debt that lives in people’s heads can’t.
- Track the interest, not just the principal. The question isn’t “how ugly is this code?” It’s “how often does this slow us down?” Debt in code nobody touches can wait. Debt in code you change every sprint is costing you now.
- Watch for triggers. End-of-life dates, unsupported versions and single points of knowledge are where avalanches start. Put the dates in the calendar before they arrive.
- Pay continuously. A fixed share of every sprint spent on debt is far cheaper than a crisis quarter spent on nothing else.
- Translate it. “This code is messy” sounds like an engineer’s preference. “This will stop all feature work if this dependency goes end-of-life” is a business risk people can act on.
For the register, a table is enough:
| Debt | Where it slows us | How often | What could force it | Act by |
|---|---|---|---|---|
| Framework two versions behind | Every core change; blocks library upgrades | Weekly | Vendor end of support; security advisory | Before end-of-support date |
| Build setup only one engineer understands | Release changes, onboarding | Monthly | That engineer leaves or is on leave | Next quarter |
| Flaky integration tests | Slower merges; real failures get ignored | Daily | An incident the tests should have caught | This sprint |
The snowball rolls both ways
Will Larson’s An Elegant Puzzle describes a team that’s “treading water”: it gets its critical work done but can’t start paying down debt. That’s the snowball phase exactly. Everything looks fine, and the debt quietly grows.
Larson uses the snowball image too, but in the opposite direction. Once a team starts repaying debt, it benefits from what he calls the debt repayment snowball: “each piece of debt you repay leads to more time to repay more debt.” Debt compounds, but so does repaying it, as long as someone makes time for the first few payments.
Where AI fits
AI coding assistants make both snowballs roll faster. They can add code quicker than a team can understand it, which grows debt faster than before. But they’re also genuinely good at the slow repayment work: dependency upgrades, migrations, missing tests, and explaining code nobody remembers writing. Used deliberately, AI makes those first few repayments cheaper, which is exactly where the repayment snowball needs a push.
The lead’s job
Developers usually see the snowball first. But debt has no owner, no date and no stakeholder on the roadmap, so it loses every prioritisation conversation by default.
That makes it a lead’s job to notice when the snowball is getting dangerous, decide which debt actually matters, and turn it into a risk the rest of the organisation can see and plan for. The best outcome is a boring one: the end-of-life date arrives, the upgrade is already done, and nobody outside the team ever hears about it.