DETTE TECHNIQUE ET ENTROPIE DU LOGICIEL — FlowCon 2018

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.

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE

November 27, 2018
Tweet

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
  5. None
  6. None
  7. None
  8. Requirements / Analysis 1 Design / Architecture 2 Development 3

    Test 4 Maintenance 5
  9. Development 1 Death 2

  10. None
  11. None
  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 ?

  17. None
  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 ?
  35. None
  36. SYMPTOMES ≠ CAUSES (ET LES MEMES CAUSES PRODUISENT LES MEMES

    SYMPTOMES)
  37. OVER-INGENIEURIE

  38. PLUS DE X POUR RESOUDRE X

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