The term comes from software development but means something quite commercial. Taking a shortcut to hit a date borrows time. It is repaid not in one sum but in small instalments, every time somebody later changes that part.
While little changes, little interest falls due. An application full of shortcuts that nobody touches any more is therefore not a problem. What gets expensive is the combination of shortcuts and a business that keeps developing.
Where the debt comes from
Rarely from carelessness. The three most common sources are unremarkable.
Deadline pressure. A trade fair, a campaign, a law with a commencement date. You build the solution that will be ready by Friday and intend to tidy it later. Later never arrives on its own, because the next date is already there.
Changed requirements. The application was built for one site and now serves four. For one client company, and now for twelve. The original structure was right; it simply no longer suits today’s job.
Knowledge that walked out. The people who knew why something was built that way have moved on. What remains is code nobody dares to change, because it is unclear what depends on it.
How you notice without reading code
You do not need a developer to judge the state roughly. Five observations are enough.
- Estimates for comparable changes are noticeably higher than they used to be.
- Asked whether something is possible, people first pause for a long time.
- Fixed bugs reappear somewhere else.
- New team members take unusually long before they can contribute.
- Nobody wants to release anything before a public holiday.
The last one tells you most. Where a release takes courage, the safety net of tests and a rehearsed way back is missing.
What actually helps
Clean-up during normal work, tied to the job that is happening anyway. Whoever touches a module leaves it better than they found it. That sounds modest and is, measured across a year, the most effective single measure, because it applies exactly where the work really happens.
Tests belong with it, at the points where a fault hurts. Not everywhere, which would be waste. But wherever money, deadlines or permissions are calculated, a test is the precondition for somebody daring to change something later.
And it needs a line in the budget. If clean-up only happens when there is spare capacity then it does not happen, because there never is any.
What rarely helps
The grand rebuild. It looks tempting because it promises to solve the problem in one move. In practice it starts from nothing while the old application still has to be maintained, and along the way it loses the knowledge held in the many special cases of the old system.
When a rebuild is nevertheless the right route is covered in a separate piece on rebuilding or repairing. In most cases the answer is a step-by-step replacement.
Where your application stands is what a software audit tells you. To keep the line flat afterwards, clean-up belongs in maintenance rather than in a project somebody applies for one day.
