Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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.

Slide 3

Slide 3 text

DETTE TECHNIQUE & COMPLEXITE @lilobase https://lgo.group

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

Requirements / Analysis 1 Design / Architecture 2 Development 3 Test 4 Maintenance 5

Slide 9

Slide 9 text

Development 1 Death 2

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

COMPLEXITE ESSENTIELLE COMPLEXITE OBLIGATOIRE COMPLEXITE ACCIDENTELLE

Slide 13

Slide 13 text

RECODEZ TWITTER EN 2 HEURES

Slide 14

Slide 14 text

Complexity System size LA COMPLEXITE EST NON-LINEAIRE

Slide 15

Slide 15 text

“TENDANCE NATURELLE D’UN SYSTEME A SE DESORDONNER” ENTROPIE COMPLEXITE ACCELERE

Slide 16

Slide 16 text

MICRO-SERVICES ?

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

SUPPRIMER UNE DUPLICATION C’EST CREER DU COUPLAGE

Slide 19

Slide 19 text

Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY PRODUCT CATEGORY CATEGORY PRODUCT PRODUCT

Slide 20

Slide 20 text

Line Invoice PRODUCT Line Line PRODUCT PRODUCT INVENTORY CATEGORY CATEGORY CATEGORY

Slide 21

Slide 21 text

IL Y A PLUSIEURS METIERS DANS UNE APPLICATION ET VOUS NE DEVEZ PAS LES COUPLER

Slide 22

Slide 22 text

MAIS N’OUBLIEZ PAS QUE FAIRE SIMPLE N’EST PAS FACILE… (ET QUE CE QUI PARAIT COMPLEXE N’EST PEUT ETRE QUE COMPLIQUE)

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

MAIS VOUS, VOUS AVEZ CHOISI DE PRENDRE DE LA DETTE TECHNIQUE ?

Slide 25

Slide 25 text

ET C’EST UN PROCESSUS BENEFIQUE POUR UN PROJET…

Slide 26

Slide 26 text

SANS ETRE UNE EXCUSE A FAIRE N’IMPORTE QUOI…

Slide 27

Slide 27 text

QUI EST UNE DECISION BUSINESS

Slide 28

Slide 28 text

AVONS-NOUS LE TEMPS DE REDEVELOPPER LA FONCTIONNALITE ?

Slide 29

Slide 29 text

TIME FEATURES BUYING TECHNICAL DEBT REIMBURSEMENT

Slide 30

Slide 30 text

LES DEVELOPPEURS ONT LE DERNIER MOT SUR LE REMBOURSEMENT

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

FINALEMENT, SI VOUS N’AVEZ PAS DE LA DETTE… QU’EST CE QUE VOUS AVEZ ?

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

SYMPTOMES ≠ CAUSES (ET LES MEMES CAUSES PRODUISENT LES MEMES SYMPTOMES)

Slide 37

Slide 37 text

OVER-INGENIEURIE

Slide 38

Slide 38 text

PLUS DE X POUR RESOUDRE X

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

Whenever I see job titles like react developper, I think about Hammer Carpenter or Spoon Cook « » @salomvary SE CONCENTRER SUR LES OUTILS

Slide 41

Slide 41 text

CARGO-CULTING

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

FAIRE DU GENERIQUE TECHNIQUE MÉTIER GÉNÉRIQUE SPÉCIFIQUE Framework technique Framework d’entreprise DDD

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

[Une des pire dette est] la dette fonctionnelle quand le métier finit par s’aligner sur une mauvaise application « » @ygrenzinger BUSINESS-TECHNIQUE

Slide 47

Slide 47 text

DECOUVRIR ET NON INVENTER

Slide 48

Slide 48 text

CODE IS LAW

Slide 49

Slide 49 text

ET ARRIVE LE CODE LEGACY…

Slide 50

Slide 50 text

Code that’s too scary to update and too profitable to delete « » LEGACY CODE – @dylanbeattie

Slide 51

Slide 51 text

Software is meant to be soft (easy to change) as opposed to hardware « » LEGACY CODE

Slide 52

Slide 52 text

COMMENT NE PLUS AVOIR PEUR DE CHANGER LE CODE ?

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

LA POURRITURE, CA SE PROPAGE

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

MERCI ! @LILOBASE https://lgo.group