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

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

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

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

October 16, 2018
Tweet

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
  6. None
  7. None
  8. None
  9. None
  10. None
  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 ?

  16. None
  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 ?
  32. None
  33. SYMPTOMES ≠ CAUSES (ET LES MEMES CAUSES PRODUISENT LES MEMES

    SYMPTOMES)
  34. OVER-INGENIEURIE

  35. PLUS DE X POUR RESOUDRE X

  36. None
  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