💸 Only take on technical debt when it will deliver business advantage.
- Make an explicit decision to take on the debt, don't just let it creep into the code base.
- Meeting a deadline is rarely a sufficient justification. Prefer instead to renegotiate time and scope. Remember too the pareto principle. It may be be that delivering the 80% that takes 20% of the effort can buy sufficient client satisfaction to offset delays in delivering parts of the remaining 20%.
💸 Only take on technical debt when you can afford it.
- Technical debt will hinder one or more of the (non-functional) ~ilities of software development. Be aware of the impact as accept it.
💸 Measure the level of debt objectively.
- A tool such as SonarQube can help a great deal here.
Repayment options:
💰 Don't repay it.
- If the features are working reliably and the debt accrued is not hindering development, there may be little business value in addressing the technical debt.
💰 Follow the "scout" principle.
- Adopt a development culture of continuing to leave the code cleaner and healthier each time it is worked on. In this way, the more defect-prone, or feature-intensive parts of the software improve and become easier to work with over time.
💰 Set up a "repayment plan".
- Agree to pay a "tax" of a %age of developer effort per sprint / iteration on addressing technical debt.
- Product managers should be involved in selecting which items of technical debt to resolve. This will make them more aware of the impact of decisions, and they can provide guidance as to areas that are on the roadmap, or where users have complained, or areas that are not worth investing in.
Comments
Post a Comment