The metaphor of Technical debt has gained currency since Ward coined it. Paying off your tech debt can be thought of as "technical investment": one hopes to reap rewards somewhere down the road, in the form of fewer defects, being able to add features more easily, and so forth.
Just like saving real money, trying to muster the will to pull this off can be difficult. The organization may balk at the notion of sinking the tech team's time into making changes that don't have an immediate customer-visible benefit. Even the tech folks can be unsure that it's going to pay off -- will the code you refactor now be instrumental in the next round of changes, or be thrown out and completely replaced a few iterations from now? Recently, I saw a remarkably clear example of the utility of paying off technical debt.
Backstory: we own a large legacy web application, created by an outsourced development company over a period of years. This application grew to the point where the company that wrote it was unable to maintain it or to add new features. It was brought in house and turned over to a small team of crack developers in the hope that they could bring it under control. In other words, right from day one, the dev team has been saddled with a huge mass of technical debt.
Our app sends a lot of email: monthly account statements, bills, proposals, dialog between users and staff, dialog between users, news and policy updates...the list goes on. As fate would have it, several pressing items to mail all landed right at the same time last month. Combined with an increasing number of clients, this put us well over the limits of our email setup. We needed to rework how our app sent outgoing mail; specifically, we needed it to be able to algorithmically choose from a list of outbound mailservers. The longer we took to make this change, the longer our clients' documents would be delayed.
This kind of thing can be a nightmare. The codebase we're working with doesn't have anything approximating a consistent architecture. The different modules of the system were almost certainly written months apart and by different developers. There's no reason to expect that each function that sends mail does so through the same interface; in fact, given our history with it, there's every reason to suspect that somewhere deep in the guts of the system, there's a well-obscured routine with its own little mailserver configuration hardcoded into it. Sorting through something like this would probably take a few days; the better part of a week for the whole change with testing and release factored in.
About two months ago, however, one of our developers went through the system with a fine-toothed comb, looking for every place the app sends mail. They got rid of the patchwork of ad-hoc methods that were littered through the code and routed all mail sending through a single consolidated class. When it came time to make a change, then, the dev got to make it in one place instead of tracking down multiple places to change or refactor, and I got to focus on how the new mail setup worked instead of trying to find places in the code that bypassed it. The new feature was developed, tested, and rolled out in a single day.
Whether we'd done the consolidation part of the work before or after we found out that our mail setup needed fixing, the total time to make the entire change probably would have been about the same. Had we not paid off our debt, though, this week would have come at a time when we could ill afford to spend it. In short, we were better prepared to react. If we had wanted to make a different change, like digitally signing all of our outbound email, this consolidation would have helped us do that as well.
So there you have it. It's only a single anecdote, but it's a point of reassurance that paying off your technical debt now can work in your favour down the road.
