Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Technical Debt

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.

Mehdi Lahmam B.

May 24, 2019
Tweet

More Decks by Mehdi Lahmam B.

Other Decks in Programming

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