Technical Debt

Le terme "dette technique" est devenu fourre-tout dès qu'on veut décrire un bout de code qui mérite d'être repris. Cette mauvaise interprétation de la métaphore et confusion mène à des décisions désastreuses sur nos projets. Qu'est-ce qui est dette technique ? Qu'est ce qui ne l'est pas ? Pourquoi devrions-nous nous en préoccuper ? Quel est le coût de la confusion ? Que faire ? Cette présentation me permettra de discuter des origines de la métaphore, expliquer ce qu'est la dette technique, et comment l'identifier au sein d'un projet et la gérer.

Transcript

1. Technical Debt
   

   View Slide

2. Mehdi Lahmam
   @mehlah
   

   View Slide

3. Technical debt anyone?
   

   View Slide

4. “Legacy code”
   

   View Slide

5. “stuff that will cost us time
   and money later”
   

   View Slide

6. “a series of bad decisions”
   

   View Slide

7. Shipping first-time code is like
   going into debt.
   — Ward Cunningham, 1992
   “
   

   View Slide

8. Shipping first-time code is like
   going into debt. A little debt
   speeds development so long as
   it is paid back promptly with a
   rewrite.
   — Ward Cunningham, 1992
   “
   

   View Slide

9. Shipping first-time code is like
   going into debt. A little debt
   speeds development so long as
   it is paid back promptly with a
   rewrite. The danger occurs
   when the debt is not repaid.
   Every minute spent on not
   quite right code counts as
   interest on that debt.
   — Ward Cunningham, 1992
   “
   

   View Slide

10. The danger occurs when the debt is not repaid. Every
    minute spent on not quite right code counts as interest
    on that debt.
    “
    

    View Slide

11. The danger occurs when the debt is not repaid. Every
    minute spent on not quite right code counts as interest
    on that debt.
    “
    

    View Slide

12. The danger occurs when the debt is not repaid. Every
    minute spent on not quite right code counts as interest
    on that debt.
    “
    

    View Slide

13. The danger occurs when the debt is not repaid. Every
    minute spent on not quite right code counts as interest
    on that debt.
    “
    

    View Slide

14. Technical debt
    is good
    

    View Slide

15. View Slide

16. Technical debt
    is good
    

    View Slide

17. Technical debt
    is a strategic design decision
    

    View Slide

18. Technical debt
    is a strategic design decision
    Allow for rapid delivery
    To elicit quick feedback
    And correct design
    

    View Slide

19. Technical debt
    is an indication of learning
    

    View Slide

20. Technical debt
    is an indication of learning
    Now know what you need
    Implementation doesn’t match
    

    View Slide

21. Technical debt
    is a metaphor
    

    View Slide

22. Technical debt
    is a metaphor
    Here be danger
    

    View Slide

23. When metaphors go wrong
    

    View Slide

24. Technical debt quadrant
    — Martin Fowler, 2009
    

    View Slide

25. Prudent
    Reckless
    Deliberate
    Inadvertent
    

    View Slide

26. Prudent
    Reckless
    Deliberate
    Inadvertent
    “We must ship now
    and deal with consequences”
    “We don’t have time
    for design”
    “Tests? What tests?” “Now we know how
    we should have done it”
    

    View Slide

27. — Ward Cunningham, 2009
    Nope!
    

    View Slide

28. [Many] have explained the debt
    metaphor and confused it with
    the idea that you could write
    code poorly with the intention
    of doing a good job later.
    — Ward Cunningham, 2009
    “
    

    View Slide

29. The ability to pay back debt […]
    depends upon you writing code
    that is clean enough to be able
    to refactor as you come to
    understand your problem.
    — Ward Cunningham, 2009
    “
    

    View Slide

30. The ability to pay back debt […] depends upon you
    writing code that is clean enough to be able to refactor
    as you come to understand your problem.
    “
    

    View Slide

31. Clean code is a perquisite
    to technical debt
    

    View Slide

32. View Slide

33. Do I have a technical debt?
    

    View Slide

34. Manager: When will the new permission be done?
    Junior developer: Mmmm, I hope tomorrow, in the end of the day.
    Manager: We need it today. Can’t you find a “creative” way to do it?
    Junior developer: Let me think…
    Manager: We have 5 clients that really need this today. Else they will
    probably not sign the contract.
    Junior developer: But the…
    Manager: Look, it’s important that you understand the business value of
    it. Isn’t it just a new condition in the code? Just put it there, and we’ll “fix
    it” later.
    Junior developer: Ok.
    Manager: So we’ll be able to deploy today?
    Junior developer: Aham.
    

    View Slide

35. Manager: When will the new permission be done?
    Junior developer: Mmmm, I hope tomorrow, in the end of the day.
    Manager: We need it today. Can’t you find a “creative” way to do it?
    Junior developer: Let me think…
    Manager: We have 5 clients that really need this today. Else they will
    probably not sign the contract.
    Junior developer: But the…
    Manager: Look, it’s important that you understand the business value of
    it. Isn’t it just a new condition in the code? Just put it there, and we’ll “fix
    it” later.
    Junior developer: Ok.
    Manager: So we’ll be able to deploy today?
    Junior developer: Aham.
    * Any resemblance to actual persons, living or dead, 

    or actual events is purely coincidental
    

    View Slide

36. Do I have a technical debt?
    

    View Slide

37. Is there a learning opportunity?
    Is there a plan for payback?
    Is the business truly informed?
    Is the code clean?
    Is the code tested?
    Do I have a technical debt?
    

    View Slide

38. You have a mess
    

    View Slide

39. You have a mess
    cruft
    
    

    View Slide

40. It’s not just semantics
    

    View Slide

41. Technical debt is good
    

    View Slide

42. Technical debt is good
    Quick and dirty is technical debt
    

    View Slide

43. Technical debt is good
    Quick and dirty is technical debt
    Quick and dirty is good
    

    View Slide

44. Technical debt is good
    Quick and dirty is technical debt
    Quick and dirty is good
    

    View Slide

45. Technical Debt quadrant revisited
    

    View Slide

46. View Slide

47. View Slide

48. View Slide

49. View Slide

50. Prudent
    Reckless
    Deliberate
    Inadvertent
    “We must ship now
    and deal with consequences”
    “We don’t have time for design”
    “What’s layering?” “Now we know how
    we should have done it”
    

    View Slide

51. Prudent
    Reckless
    Deliberate
    Inadvertent
    “We must ship now
    and deal with consequences”
    “We don’t have time for design”
    “What’s layering?” “Now we know how
    we should have done it”
    Incompetent
    

    View Slide

52. Prudent
    Reckless
    Deliberate
    Inadvertent
    “We must ship now
    and deal with consequences”
    “We don’t have time for design”
    “What’s layering?” “Now we know how
    we should have done it”
    Irresponsible
    Incompetent
    

    View Slide

53. Prudent
    Reckless
    Deliberate
    Inadvertent
    “We must ship now
    and deal with consequences”
    “We don’t have time for design”
    “What’s layering?” “Now we know how
    we should have done it”
    Irresponsible
    Incompetent
    Technical debt
    Technical debt
    

    View Slide

54. The trap!
    

    View Slide

55. Precedent for speed over quality
    Expectation of increased velocity
    Cruft slows you down
    Must write more cruft to keep up
    Ask permission to do your job correctly
    

    View Slide

56. It makes even experienced developers fall into
    rookie mistakes
    It kills developers’s passion, sometimes
    permanently, making the best developers leave
    It destroys accountability, since the hurry becomes
    a   good excuse for mistakes
    It erodes trust between management and the tech
    team, sometimes permanently
    

    View Slide

57. Managing cruft
    

    View Slide

58. Cleaning iteration
    A failing strategy
    

    View Slide

59. Cleaning iteration
    A failing strategy
    Schedule iterations for cleaning code
    Defer quality to cleaning sprint
    Focus on speed/velocity at all other times
    

    View Slide

60. View Slide

61. Clean constantly
    A winning strategy
    

    View Slide

62. Clean constantly
    A wining strategy
    Never make an intentional mess
    Monitor your technical debt
    Follow the Boy Scout Rule
    

    Remember quality is your responsibility
    Never ask permission to do your job correctly
    

    View Slide

63. Monitor your cruft
    Code Coverage
    Code Complexity
    Coupling
    Maintainability
    Monitor trends, not points
    

    View Slide

64. Tech debt Cruft
    Happens
    Needs to be monitored
    Is not technical debt
    A strategic decision
    Require business to 

    be informed
    Includes a pay-back plan
    

    View Slide

65. View Slide