Keynote Dette technique & Entropie du logiciel – Orange Dev Test days 2018

Transcript

1. POURQUOI N’AVONS-NOUS PAS D’ARAIGNEE DE LA TAILLE D’UN ELEPHANT ?
2. EST-CE QU’IL EST PLUS IMPORTANT D’ALLER CHEZ LE DENTISTE OU DE SE LAVER LES DENTS TOUS LES JOURS ?
3. 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
4. DETTE TECHNIQUE & COMPLEXITE @lilobase https://lgo.group
5. 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
11. COMPLEXITE ESSENTIELLE COMPLEXITE OBLIGATOIRE COMPLEXITE ACCIDENTELLE
12. RECODEZ TWITTER EN 2 HEURES
13. Complexity System size LA COMPLEXITE EST NON-LINEAIRE
14. “TENDANCE NATURELLE D’UN SYSTEME A SE DESORDONNER” ENTROPIE COMPLEXITE ACCELERE
15. MICRO-SERVICES ?
17. ENFIN, NE SOYEZ PAS TROP DRY…
18. Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY PRODUCT CATEGORY CATEGORY PRODUCT PRODUCT
19. Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY CATEGORY CATEGORY
20. MAIS N’OUBLIEZ PAS QUE FAIRE SIMPLE N’EST PAS FACILE… (ET QUE CE QUI PARAIT COMPLEXE N’EST PEUT ETRE QUE COMPLIQUE)
21. 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
22. MAIS VOUS, VOUS AVEZ CHOISI DE PRENDRE DE LA DETTE TECHNIQUE ?
23. ET C’EST UN PROCESSUS BENEFIQUE POUR UN PROJET…
24. SANS ETRE UNE EXCUSE A FAIRE N’IMPORTE QUOI…
25. QUI EST UNE DECISION BUSINESS
26. AVONS-NOUS LE TEMPS DE REDEVELOPPER LA FONCTIONNALITE ?
27. LES DEVELOPPEUR ONT LE DERNIER MOT SUR LE REMBOURSEMENT
28. 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
29. 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
30. 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
31. FINALEMENT, SI VOUS N’AVEZ PAS DE LA DETTE… QU’EST CE QUE VOUS AVEZ ?
33. SYMPTOMES ≠ CAUSES (ET LES MEMES CAUSES PRODUISENT LES MEMES SYMPTOMES)
34. OVER-INGENIEURIE
35. PLUS DE X POUR RESOUDRE X
37. Whenever I see job titles like react developper, I think about Hammer Carpenter or Spoon Cook « » @salomvary SE CONCENTRER SUR LES OUTILS
38. CARGO-CULTING
39. 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
40. 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
41. FAIRE DU GENERIQUE TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique Framework d’entreprise DDD
42. 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
43. [Une des pire dette est] la dette fonctionnelle quand le métier finit par s’aligner sur une mauvaise application « » @ygrenzinger BUSINESS-TECHNIQUE
44. CODE IS LAW
45. DECOUVRIR ET NON INVENTER
46. ET ARRIVE LE CODE LEGACY…
47. Code that’s too scary to update and too profitable to delete « » LEGACY CODE
48. Software is meant to be soft (easy to change) as opposed to hardware « » LEGACY CODE
49. COMMENT NE PLUS AVOIR PEUR DE CHANGER LE CODE ?
50. 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
51. LA POURRITURE, CA SE PROPAGE
52. 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
53. MERCI ! @LILOBASE https://lgo.group