Tuesday, April 15, 2014

Technical Debt Patterns

(More details – article Know and Manage the Technical Debt, Software Development Journal)

Prevention_Versus_Correction 
  • 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.
Levels_of_Design_Versus_Debt 
  • 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
No_trade_for_basic_levels 
  • “Bad code is always imprudent.” says Robert C. Martin 
 Methodology_Induced_Debt 
  • 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.
 Avoid_Mega_Debts 
  • 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 
 Register_the_debt 
  • In order to manage and pay the debt , you should know and register the debt
Manage_Mega_Debts_First 
  • Big, important and messy – that is an explosive problem.
Define_and_Use_Thresholds 
  • Beyond applying metrics, should be associated some risks thresholds to some significant metrics.
Search_Usual_Suspects 
  •  Feature envy, big size, no separation of concerns; searching for them could offer a quick assessment and a quick reaction
Use_Separation_Of_Concerns
  • That is the design principle with biggest impact on debt management.
Long_Term_Steadiness
  •  See Software Craftsmanship Manifesto
Honest_development
  • Clearly define the responsibility of managing the TD