The word “Technical Debt” has come a long way since it was first introduced by Ward Cunningham in early 1990s.
The word “Technical Debt” makes sense as most of us are aware about the meaning of “Financial Debt”, which means paying interests all the time unless you repay your principle amount.
Similarly Technical Debt means that we need to pay interests (in terms of our design or code capability) all the time unless we re-factor our earlier design or code (the principle).
However, somewhere during the rush hour to find technical debt we've start characterizing every coding / designing shortcut as technical debts. We should just be very clear that there is a fundamental difference between a Technical Debt and a Financial Debt.
In a Financial Debt, you always know the amount of interest that one needs to pay all the time and what’s your principle outstanding. However, in a Technical Debt you neither know the amount of interest you will pay nor the cost to pay your principle (i.e. Effort to re-factor the design or code).
For design / code, it’s unlikely that we can quantify the interest cost unless the shortcuts are causing very trivial side effects like increase memory / flash footprint, cache misses etc.
In reality, people are trying to analyze the design and code from the perspective of whether the code can be extended to support additional feature or it’s looking ugly and difficult to understand so it needs to be re-factored and so on.
I’d like to advice against considering these designs and codes as Technical Debt.
An ugly looking code which is working fine and may not be required to change in near future is not a technical debt.
A design or code which shows little sign of being extendable is not a technical debt unless there is an immediate need to extend it.
It’s wise to remember the financial cost of being future proof which nobody really knows about. The cost of redoing things a new way in future may be much smaller than to keep on refactoring in assumption of future needs, which nobody can predict and control.
To summaries, if you’re given a chance to identify and fix technical debt, use that opportunity wisely.
Just a thought
(Disclaimer : The opinion is purely mine and it doesn't reflect the views of the organization I'm employed with)
Last Visit: 31-Dec-99 18:00 Last Update: 24-May-16 10:00