Tuesday, April 15, 2014

Technical Debt Patterns

(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;
    • Big_Design_Elements 
  • 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