Every long-running software project carries technical debt, and the people who fund the project usually hear about it only once it has become expensive. A shortcut gets taken to make a date, perhaps the GST filing module has to go live before the quarter closes, and nobody writes it down. A year later a small change takes three weeks, a postponed framework upgrade turns urgent because of a security advisory, and a new developer from the Pune office needs a month to understand one module. The shortcut was often a fair call at the time, and losing track of it is what turned it into a bill.
What Technical Debt Actually Is
Technical debt is the extra work you will do later because you chose a quick solution now. The loan comparison holds up better than most. Like a loan, it carries interest, and the longer it sits, the more every later change in that area costs. Unlike a loan, nobody sends you a statement, so unless someone keeps the books the balance is a guess.
It comes in a few familiar forms. The first column below is what engineers call it; the third is what I ask first when I am trying to size it.
| Form | How it shows up | First question to ask |
|---|---|---|
| Messy code | Duplicated logic, unclear names, little documentation | Where do the same bugs keep coming back? |
| Outdated frameworks | Upgrades postponed, security patches hard to apply | How far behind are the main dependencies? |
| Tangled structure | A change in one area breaks another | Which module does almost every change touch? |
| Skipped tests | Nobody wants to change anything | Which critical flows have no automated test? |
For a first version of a product, some debt is sensible, and we take it on knowingly ourselves when a launch date matters more than polish. The trouble in long-lived projects is debt that nobody decided on. There is nothing to pay back deliberately, because nobody knows what was borrowed.
Where the Cost Shows Up
The cost shows up later, and it rarely arrives labelled. Features take longer because each one needs extra care around the fragile parts. Bugs take longer to fix. Developers spend afternoons working out what old code does instead of building anything new, and outdated dependencies leave security gaps that keep pushing planned work down the list.
Picture an NBFC whose branch system has a loan-disbursal module patched by six different developers over four years. Every rate change touches it, every change needs two reviewers who are nervous of it, and the move to a supported framework version has been "next quarter" for two years. Nobody in that company ever approved spending on debt. They are paying for it anyway, in slower rate changes and in senior developer time, and it never appears as a line in the budget.
- 01Shortcut takento meet a date
- 02Not recordedno ticket, no owner
- 03Interest buildseach change costs more
- 04Forced repairduring an incident or upgrade
The chain breaks at step two, when nobody records the shortcut.
Debt You Chose and Debt You Found
- Chosen to meet a date
- Written down with a reason
- Has an owner and a review date
- Comes from rushed or unclear work
- Known only to whoever wrote it
- Found when it breaks
The difference is whether anyone chose it and wrote it down.
Taking on short-term debt for a launch or a client commitment is a fair business decision if it is made in the open and paid back soon. The finance head would never let a loan go unrecorded, and a shortcut deserves the same treatment. The register described at the end of this piece matters more than any refactoring tool, because it moves debt from the right-hand column to the left.
How Projects Lose Track of It
The root of most of it is simple. The shortcut is never written down, so it can never be scheduled. Requirements change, nobody revisits the structure, and new features get bolted onto a design built for the old ones. Without coding standards or a review habit, every developer solves the same problem a different way, and the codebase ends up with four ways to format a date and three ways to call the payment gateway.
Refactoring, meaning restructuring code without changing what it does, stays on next sprint's list forever. "It works for now" stays true right up to the day the person who understood it resigns. Dependencies are left alone because upgrades feel risky, which makes each upgrade bigger and riskier. And business and engineering use different words for the same thing. Engineers say debt, and managers hear a request for time with nothing to show at the end of it.
That last gap is the one I spend the most time on. If the engineering lead cannot say what a piece of debt costs per month in delayed work, the product owner will always choose the feature, and from where they sit that is the right choice.
Habits That Keep the Balance Down
Design for growth, in proportion
Even a simple start needs a structure that can take more features without a rewrite, which mostly means clear module boundaries and a sensible data model. That is different from designing for traffic you do not have. The trade-offs in building software architecture that can grow are worth reading before the first module is written.
Review every change against agreed standards
Linting, code review and short written notes keep the style consistent and spread knowledge across the team. They matter more when the team is split between Noida and Bengaluru and nobody can lean over a desk to ask.
Test the paths that carry money
Unit tests, integration tests and an automated build pipeline catch regressions early and make refactoring safe enough that people will actually do it. Start with the flows that move money or create legal records.
Refactor where the work already is
We reserve some time in each sprint for cleanup tied to the area being worked on anyway. If the sprint touches invoicing, the cleanup happens in invoicing. Small improvements are easier to review and easier to defend to a product owner who wants to see features, and they fit the short cycles described in our piece on Agile delivery that reaches users early.
Keep dependencies current in small steps
A routine minor update is far cheaper than a jump across several versions forced by a security issue in the week before a release. Put a recurring date in the calendar for it, the same way month-end close has a date.
Start a Debt Register This Week
The register is one shared list. It does not need a tool; a spreadsheet the product owner can read is enough. Each entry carries four things.
| Shortcut | Why it was taken | Cost of leaving it | Owner |
|---|---|---|---|
| Hard-coded tax rates in invoicing | Launch before quarter close | Every rate change needs a release | Billing lead |
| Payment gateway called three ways | Three developers, no shared module | Each gateway change done three times | Backend lead |
Then follow these steps in order:
- Spend an hour with the team listing the shortcuts everybody already knows about.
- Rank the entries by how often that code is touched, not by how ugly it is.
- Put one entry into each sprint, and show the product owner what it bought.
- Add a rule for new work: any shortcut gets a register entry before it merges.
The first step is the one to book now. An hour in a meeting room will show what needs fixing this quarter and what can wait, and it turns a vague complaint from engineering into a list a product owner can sign off. Put a date on that hour before the week is out, and invite the product owner, because they are the one who will be choosing between the register and the next feature.
