Why should one know about Technical Debt?
What is Technical Debt?
An analogy between bankruptcy and technical bankruptcy is the best example to look at the concept of Technical Debt. If a person takes a loan, he starts paying installments for it. If for some reason, at the start he is not able to pay these installments, interst will keep increasing, so also his debt will increase. If the number of unpaid installments increases, interest incurred also increases. At last, when no installments are paid the person will be declared bankrupt.
In a similar way, when the development of software starts, if the design isn’t refactored frequently, after some time it will result in bad software to the point where we have to throw that software as it is no longer manageable. When we say refactoring is not done, it means there is the increase in debt called “Technical Debt”.
What constitutes TD?
Bad coding style, violating design rules, violating code analysis tools results, having bad smells in code, lack of testing, inadequate test coverage, lack of documentation or not following code reviews.
How is TD introduced?
Scheduled pressure, lack of skilled designers, lack of application of design principles, lack of awareness of refactoring and design smells.
To make software manageable, awareness of Technical Debt is very important in the software industry. Looking forward to spreading this awareness.
For more information, I’d like to refer you to the book ‘Refactoring for Software Design Smells: Managing Technical Debt’ by author Ganesh Samarthyam.