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
2. Mehdi Lahmam @mehlah
3. Technical debt anyone?
4. “Legacy code”
5. “stuff that will cost us time and money later”
6. “a series of bad decisions”
7. Shipping first-time code is like going into debt. — Ward Cunningham, 1992 “
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 “
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 “
10. The danger occurs when the debt is not repaid. Every minute spent on not quite right code counts as interest on that debt. “
11. The danger occurs when the debt is not repaid. Every minute spent on not quite right code counts as interest on that debt. “
12. The danger occurs when the debt is not repaid. Every minute spent on not quite right code counts as interest on that debt. “
13. The danger occurs when the debt is not repaid. Every minute spent on not quite right code counts as interest on that debt. “
14. Technical debt is good
16. Technical debt is good
17. Technical debt is a strategic design decision
18. Technical debt is a strategic design decision Allow for rapid delivery To elicit quick feedback And correct design
19. Technical debt is an indication of learning
20. Technical debt is an indication of learning Now know what you need Implementation doesn’t match
21. Technical debt is a metaphor
22. Technical debt is a metaphor Here be danger
23. When metaphors go wrong
24. Technical debt quadrant — Martin Fowler, 2009
25. Prudent Reckless Deliberate Inadvertent
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”
27. — Ward Cunningham, 2009 Nope!
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 “
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 “
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. “
31. Clean code is a perquisite to technical debt
33. Do I have a technical debt?
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.
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
36. Do I have a technical debt?
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?
38. You have a mess
39. You have a mess cruft
40. It’s not just semantics
41. Technical debt is good
42. Technical debt is good Quick and dirty is technical debt
43. Technical debt is good Quick and dirty is technical debt Quick and dirty is good
44. Technical debt is good Quick and dirty is technical debt Quick and dirty is good
45. Technical Debt quadrant revisited
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”
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
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
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
54. The trap!
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
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
57. Managing cruft
58. Cleaning iteration A failing strategy
59. Cleaning iteration A failing strategy Schedule iterations for cleaning code Defer quality to cleaning sprint Focus on speed/velocity at all other times
61. Clean constantly A winning strategy
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
63. Monitor your cruft Code Coverage Code Complexity Coupling Maintainability Monitor trends, not points
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