DETTE TECHNIQUE ET ENTROPIE DU LOGICIEL — FlowCon 2018

Souvent mal comprise et confondue avec l’érosion du logiciel, la dette technique a mauvaise presse. Elle reste pourtant un processus essentiel (si maitrisé correctement) lors des développements. A contrario, l’entropie logicielle est un phénomène naturel conduisant progressivement le logiciel à perdre en maintenabilité et évolutivité. Nous étudierons les causes d’accélération de cette entropie, mais surtout, comment combattre ce processus qui finit par bloquer l’évolution du logiciel (et au passage sa rentabilité) ? Une conférence ouverte à tous (y compris non développeurs), pour s’intéresser à pourquoi et comment le code source d’un logiciel finit par être immaintenable.

Transcript

1. A TICKING BOMB The ticking time bomb of technical debt is ticking louder and louder, and the clock is counting down faster and faster « » – Gartner
2. LEHMAN’S LAW OF SOFTWARE EVOLUTION "Continuing Change" — a system must be continually adapted or it becomes progressively less satisfactory "Continuing Growth" — the functional content of a system must be continually increased to maintain user satisfaction over its lifetime "Increasing Complexity" — as a system evolves, its complexity increases unless work is done to maintain or reduce it. "Declining Quality" — the quality of a system will appear to be declining unless it is rigorously maintained and adapted to operational environment changes.
3. DETTE TECHNIQUE & COMPLEXITE @lilobase https://lgo.group
4. LA DEFINITION D’ORIGINE The obligations incurred by a software organization when it chooses an expedient design or construction approach that increases complexity and is more costly in the long term « » – Ward Cunningham
8. Requirements / Analysis 1 Design / Architecture 2 Development 3 Test 4 Maintenance 5
9. Development 1 Death 2
12. COMPLEXITE ESSENTIELLE COMPLEXITE OBLIGATOIRE COMPLEXITE ACCIDENTELLE
13. RECODEZ TWITTER EN 2 HEURES
14. Complexity System size LA COMPLEXITE EST NON-LINEAIRE
15. “TENDANCE NATURELLE D’UN SYSTEME A SE DESORDONNER” ENTROPIE COMPLEXITE ACCELERE
16. MICRO-SERVICES ?
18. SUPPRIMER UNE DUPLICATION C’EST CREER DU COUPLAGE
19. Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY PRODUCT CATEGORY CATEGORY PRODUCT PRODUCT
20. Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY CATEGORY CATEGORY
21. IL Y A PLUSIEURS METIERS DANS UNE APPLICATION ET VOUS NE DEVEZ PAS LES COUPLER
22. MAIS N’OUBLIEZ PAS QUE FAIRE SIMPLE N’EST PAS FACILE… (ET QUE CE QUI PARAIT COMPLEXE N’EST PEUT ETRE QUE COMPLIQUE)
23. LA DEFINITION D’ORIGINE The obligations incurred by a software organization when it chooses an expedient design or construction approach that increases complexity and is more costly in the long term. « » – Ward Cunningham
24. MAIS VOUS, VOUS AVEZ CHOISI DE PRENDRE DE LA DETTE TECHNIQUE ?
25. ET C’EST UN PROCESSUS BENEFIQUE POUR UN PROJET…
26. SANS ETRE UNE EXCUSE A FAIRE N’IMPORTE QUOI…
27. QUI EST UNE DECISION BUSINESS
28. AVONS-NOUS LE TEMPS DE REDEVELOPPER LA FONCTIONNALITE ?
29. TIME FEATURES BUYING TECHNICAL DEBT REIMBURSEMENT
30. LES DEVELOPPEURS ONT LE DERNIER MOT SUR LE REMBOURSEMENT
31. La vélocité n’est pas bonne, il reste beaucoup de user story L’équipe génère de la « dette technique » pour accélérer Il faut résorber la dette au début du sprint suivant On arrive à la fin du sprint
32. Les temps de développement sont trop longs L’équipe n’arrive pas à fournir à temps les fonctionnalités L’équipe génère de la « dette technique » pour accélérer Il faut prendre le temps de résorber la dette
33. La complexité du système le rend ingérable Panique / Code legacy Il faut prendre le temps de résorber la dette Mais on n’a pas le temps
34. FINALEMENT, SI VOUS N’AVEZ PAS DE LA DETTE… QU’EST CE QUE VOUS AVEZ ?
36. SYMPTOMES ≠ CAUSES (ET LES MEMES CAUSES PRODUISENT LES MEMES SYMPTOMES)
37. OVER-INGENIEURIE
38. PLUS DE X POUR RESOUDRE X
40. Whenever I see job titles like react developper, I think about Hammer Carpenter or Spoon Cook « » @salomvary SE CONCENTRER SUR LES OUTILS
41. CARGO-CULTING
42. La plus forte cause d'aliénation dans le monde contemporain réside dans cette méconnaissance de la machine, qui n'est pas une aliénation causée par la machine, mais par la non-connaissance de sa nature et de son essence « » – Simondon L’ALIENATION PAR LA TECHNIQUE
43. This second is the most dangerous system a man ever designs. […] The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. « » – Brooks LE SYNDROME DU DEUXIEME SYSTEM
44. FAIRE DU GENERIQUE TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique Framework d’entreprise DDD
45. BUSINESS-TECHNIQUE On fait passer les besoins de la base de données avant ceux des utilisateurs ce qui nous donne des expériences assez pourries « » @WalterStephanie
46. [Une des pire dette est] la dette fonctionnelle quand le métier finit par s’aligner sur une mauvaise application « » @ygrenzinger BUSINESS-TECHNIQUE
47. DECOUVRIR ET NON INVENTER
48. CODE IS LAW
49. ET ARRIVE LE CODE LEGACY…
50. Code that’s too scary to update and too profitable to delete « » LEGACY CODE – @dylanbeattie
51. Software is meant to be soft (easy to change) as opposed to hardware « » LEGACY CODE
52. COMMENT NE PLUS AVOIR PEUR DE CHANGER LE CODE ?
53. An important result […] is a movement toward simplicity of design. Before I used refactoring, I always looked for flexible solutions. I would wonder how any requirement would change during the life of the system. Because changes were expensive, I would look to build a design that would stand up to the changes I could foresee. The problem with building a flexible solution is that flexible solutions are more complex than simple ones. […] Building flexibility in all these places makes the overall system a lot more complex and expensive to maintain. « » REFACTORING – Fowler
54. LA POURRITURE, CA SE PROPAGE
55. WE NEED MORE CHEFS We tend to get sidetracked by tools when we should really be thinking about what our tools are supposed to achieve. Chefs instead of recipe book user « » @_edejong
56. MERCI ! @LILOBASE https://lgo.group