Technical Debt?
Over a period of time, Software Systems accumulate internal deficiencies in code. This can happen due to various reasons like
- Initial design became inadequate as the system scaled in size and complexity
- or technical inadequacies during urgent deliverables left unattended
- or attention to internal quality left slack during some phase of development
- Many more scenarios can lead to such internal quality issues
Hence the term Technical Debt. This technical inadequacy or quality issues pile up over the period of time making it more error-prone and time-consuming to make any code changes to this piece of application. Software teams end up paying interest in terms of additional efforts due to this technical debt.
On face value, it appears straight forward and logical to take some time off and clear all technical debt. However, it is not practically doable in most cases. Further, there is always an element of subjectivity in Software design, making it difficult to claim whether the technical debt is addressed entirely or partially.
It is advisable to formally plan for technical debt clearance as a part of your software development plan. If there is a poorly designed complex piece of code that has not been changed in years then it is fine to accept this technical debt and not act on it unless needed.
If there are pieces of code which is frequently used across many features and need to be updated more frequently, then there has to be zero tolerance towards any technical debt in these sections.
There is lots of research already happened, in relation to analyzing which inadequacies to be considered as Technical Debt and which are not.
Please get in touch to take this discussion further in terms of your strategies or if you would like to understand more about our practices.
Thank you.
Best Regards,
Rupashri