Technical Debt in Coding
Make good choices
Technical debt is the implied additional cost by adding new features rather than spending time to update software to represent your understanding of existing features.
Technical debt as a metaphor
Metaphors allow us to use analogies in our language and make concepts easy to understand.
The debt metaphor originated in financial software, but is applicable to any software development project.
By continually stumbling over the same issues, it is like paying interest on a loan.
By rushing software, you eventually have to go back and effectively repay the loan to reflect your experience as you acquire it. This comes back into the software through refactoring and stumbling over issues.
If you always add new features rather than updating the program to reflect your understanding of those features mean that the program builds up issues and it takes more and more time to implement new features.
Technical debt as poorly written software
Software should represent your understanding when you wrote it. If it does not represent your understanding at any point in time, you should put the effort into making it reflect your understanding. Then when it comes to the time to refactor your work your understanding will be synchronised with the existing code.
Code should be clean enough to enable you to refactor it when the time comes.
Technical debt as a term was never intended to give programmers a way to write poorly-written software that they themselves do not understand (and I have personally heard it used as an excuse for such).
It rather relates to the relentless adding of features to a codebase without taking the time and effort to help the existing codebase to better cope with future features. This is thought of within this metaphor as technical debt, and some organisations are maxing out their credit cards as they add more features to their software and perhaps acquiring the debt deliberately.
That’s true — organisations acquire technical debt deliberately to allow them to release feature quickly and efficiently. Much like a family that borrows money to buy a house, if the debt is planned and manageable this can actually be a good thing. The issue is that code shops can sometimes take on this debt without consideration and thought — this is never a good thing.
Ward Cunningham explains the use of technical debt, and he coined the term as a metaphor during his development of financial software. However it can easily be transferred to any other problem domain, and frequently has been.
You’d be well-advised to monitor your use of technical debt in your organisation, as like any debt it does need to be paid back in the end, and this is something that you need to think about how you will plan and complete this work with (possibly) a current penchant for features.
This is certainly something you would need to think about.