(More details – article Know and Manage the Technical Debt, Software Development Journal)
- We should focus continuously on quality by adopting “built-in” quality versus “inspected-in” quality. In fact, the “test&fix” approach will give a temporary quality and will hide the debt. Finally, it is pretty naive to address quality only by test & fix.
- Because TD is related to software design, it is also related to the Levels_of_Design, where each level could introduce – more or less – its own part of technical debt. Here are some levels (others could also be taken into consideration):
- Coding style
- Clean code rules
- Design decisions in context
- Architecture decisions
- “Bad code is always imprudent.” says Robert C. Martin
- Use context-adapted iterative approach, that mean the right design strategy in the context.
- Agile techniques: Clean Code (“prefactoring”), Refactoring, TDD (pay the debt early)
- Risks-driven techniques: Architecture-driven approach.
- The cost of a such debt could be exponentially higher then of the normal debt. Examples:
- Refactoring nightmare by Interfering_Debts (such unsearchable names + “duplicate” code);
- Envious_Monster – mega components that present “”feature envy” for many other components;
- In order to manage and pay the debt , you should know and register the debt
- Big, important and messy – that is an explosive problem.
- Beyond applying metrics, should be associated some risks thresholds to some significant metrics.
- Feature envy, big size, no separation of concerns; searching for them could offer a quick assessment and a quick reaction
- That is the design principle with biggest impact on debt management.
- See Software Craftsmanship Manifesto
- Clearly define the responsibility of managing the TD