Congratulations! Technical Debt GURU level unlocked!

Congratulations! Technical Debt GURU level unlocked!

As Software Engineers we know that Technical Debt and Legacy Code are familiar concepts we have to live with in our day to day life.

We are also aware that our software, in general terms, is terrible and that does not make it any especial.

Code base healthiness and maintenance are challenging, so in this quick journey we are going to walk together through a bunch of tips and techniques on how to effectively address this problem.

12defde716586eb2d726d081a161756d?s=128

Fernando Cejas

April 29, 2019
Tweet

Transcript

  1. @fernando_cejas TECHNICAL DEBT GURU LEVEL

  2. I am Fernando Cejas I am here because I love

    to share experiences and disasters I have made in my professional life. × Twitter: @fernando_cejas × Github: @android10 × Blog: fernandocejas.com Hello!
  3. “BAD CODE IS ALWAYS imprudent”

  4. In an ideal world...every project... Finished on time Clean code

    On budget
  5. Even better… our perfect project... Additional features Tested twice ???

  6. Level

  7. None
  8. FACT: OUR SOFTWARE IS TERRIBLE!!! And that does not make

    it special. All software is terrible, and yes, we know it is definitely TRUE
  9. WHAT IS LEGACY CODE?

  10. Code without tests Code that someone else has written ANTI-PATTERNS

    No separation of concerns Code difficult to change Difficult to understand
  11. WHAT IS RECKLESS DEBT?

  12. Code that violates design principles Without even a short term

    payoff
  13. WHAT IS TECHNICAL DEBT?

  14. It is a metaphor doing things the quick and dirty

    way sets us up with a technical debt Incurs INTEREST PAYMENT which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.
  15. Technical debt is the additional effort and work REQUIRED to

    complete any software development.
  16. “TEchnical debt is reflected on legacy code”

  17. Real case scenario: ADDING A NEW FEATURE

  18. THE “EASY” WAY: Built up with messy design and code,

    will get you there faster.
  19. THE “HARD” WAY: Built up with cleaner design and code,

    that takes a lot more time
  20. “Accept some technical debt for tactical reasons”

  21. DETECTING TECHNICAL DEBT

  22. Level

  23. STATIC CODE ANALYSIS

  24. Static CODE ANALYSIS: CODE METRICS Cyclomatic complexity complexity of classes

    and methods by analyzing the number of functional paths in the code Code coverage A lack of unit tests is a source of technical debt. This is the amount of code covered by unit tests. Bug count As technical debt increases, quality of the software decreases. The number of bugs will likely grow. Number of rule violations Number of rules violated from a given set of coding conventions. SQALE-rating Broad evaluation of software quality. The scale goes from A to E, with A being the highest quality.
  25. Level

  26. TECH DEBT RADAR

  27. TECH DEBT RADAR +PAIN -PAIN +Dev TIME -Dev TIME DI

    Login Player UI Layer Photos Share Data Layer Search
  28. Level

  29. BEHAVIORAL CODE ANALYSIS

  30. “TEchnical debt is reflected on legacy code”

  31. “TEchnical debt is NOT ONLY reflected on legacy code”

  32. BEHAVIORAL CODE ANALYSIS: 1. Consider the organization and people side

    of the system. 2. This gives you valuable information that is invisible in the source code itself, such as measures of team autonomy and off-boarding risks. 3. How developers interact with the code.
  33. behavioral CODE ANALYSIS: METRICS Hotspots Hotspots identify the modules with

    most development activity -- often technical debt. Code biomarkers Code Biomarkers aim to indicate specific properties at very low code level. Refactoring Targets Prioritize improvements to these files since they have the highest technical debt interest rate. Change coupling Change coupling helps us uncover implicit change patterns in our code.
  34. EXTRA BALL!!

  35. PAYING TECHNICAL DEBT

  36. Paying debt at team level: 1. Prioritize and keep track

    of it. 2. Allocate time to address it. 3. Technical Debt days.
  37. Paying debt at COMPANY level: 1. Educate people about its

    existence. 2. Make it transparent. 3. Communicate it properly.
  38. Paying debt at COMPANY level: COST OF DELAY This (mostly

    manual) metric helps to make visible how much time a team loses due to technical debt.
  39. SOME DAYS YOU CANNOT GET RID OF A BOMB...

  40. None
  41. THANKS! Any questions? You can find me at @fernando_cejas (twitter)

    & @android10 (github)
  42. Credits Special thanks to all the people who made and

    released these awesome resources for free: × Presentation template by SlidesCarnival × Photographs by Startupstockphotos