Previous articles of mine explained about, what is the technical debt and how this impacts the total cost of ownership. The articles also included why a Product Should care about the technical debt and allow the development team to refactor the code to control the technical debt.
Anything that can be measured can be improved. For improving (lower) the technical debt, the pre-requisite is to measure it first.
Developers or sometimes the Product companies do categorize the technical debts. There are no rules defined, but one can organize the technical debts and then use some methods to deal with that.
- The debt classification:
- The debt of defects
- The debt of design
- The debt of compliance and documentation
- The debt of ignored tests
- The debt of algorithms and flawed logics
- The debt os the architecture
- The debt of team skills
- Many more…..
These debts lead to the Product pains of reliability, maintainability, portability, security, recurring issues, and many more that elevates the Product operational cost.
As a Product Owner, one must care about the technical debt, failing which causes a long-term catastrophe, where Product maintenance cost becomes higher than the revenues, and the Product ultimately gets grave.
To view the full blog and this blog "Measure and Control the Technical Debt" is originally published on Agilemania website.
