Désendetteur Technique

Dimitri Baeli d’eXo Platform a mis un nom sur notre métier, et sur ce que j’ai fait depuis un an : Désendetteur Technique. C’est l’histoire d’un message sur Twitter, qui est à l’origine de ce billet. J’ai trouvé cela génial, car cela correspond à une partie de notre activité : réduire la dette technique d’une application. A cela j’ajouterai, réduire la dette de gestion de projet en aidant une équipe à découvrir les méthodes Agiles.

Notre rôle est d’identifier et de colmater rapidement les fuites dans votre projet. Tout d’abord les fuites techniques. Prenez un excellent outil comme XDepend par exemple. C’est un peu le scanner du Docteur House. Imaginez la scène un instant… Votre application émet des signes inquiétants. Votre projet semble s’arrêter petit à petit, et personne ne sait vraiment de quoi souffre celui-ci… Il est temps d’appeler un Désendetteur Technique… Quelques heures avec des outils comme XDepend ou Sonar, et le diagnostic tombe : votre produit souffre d’une bonne complexité cyclomatique ici, et il y a un problème maven là, ainsi qu’un souci d’organisation car vous n’avez pas d’intégration continue.

Le patient: Oui là ça fait mal docteur… Non je n’ai pas lu la documentation sur Hibernate… oui j’ai mis lazy=false car je ne sais pas comment gérer ces objets, non je ne m’excuse pas pour cela…
Bref comme 20% du code coûte 80% des performances, un Désendetteur Technique sera capable de vous aider à chercher du bon côté, à corriger le souci et surtout, à éviter qu’il ne se reproduise. Soigner et éviter de retomber malade, c’est la devise d’un Désendetteur Technique.

Prenez un projet, passez le à maven2. Quelques mois plus tard c’est le foutoir. Pourquoi ? Parce qu’il faut aussi apprendre aux développeurs à se servir de Maven 2.

Concernant les fuites dans la gestion de projet, je pense que trop de projets souffrent car ils ne sont pas gérés du tout. Et la gestion projet, c’est beaucoup d’écoute, un peu d’accompagnement et très peu de directif. Un mode de gestion où le développeur doit cocher une case pour dire ce qu’il a fait lundi, où il ne peut pas fermer un bug sans que son chef n’ait vu sa correction, où il est tenu d’écrire une spécification de 100 pages avant de coder, c’est un projet mort.

L’Agilité c’est passer du Directif au Démerditif.
J’explique aux gens que ça va faire mal, ils ne vont pas aimer, ça va être difficile et ça peut même échouer. Après cela, si je suis encore là, nous pouvons travailler. En janvier lors d’un stand-up devant 15 développeurs, j’ai un peu râlé en disant qu’il fallait arracher le pansement du petit bobo pour avancer et pas tirer doucement. Faire du Scrum, c’est faire un saut de 10 mètres dans le vide. Après soit vous avez pensé à prendre un gars pour vous attacher, soit vous vous écrasez 10 mètres plus bas. Passer à l’Agilité s’apparente plus à du saut à l’élastique qu’à un saut en parachute. Vous allez faire quelques aller-retours pas forcément agréable avant que cela ne fonctionne.

Désendetteur Technique, j’adore.
Franchement merci Dimitri de mettre un nom sur ce que les experts séniors font. Prenez le livre blanc d’OCTO Technologies sur la productivité. Ce livre est vraiment bien écrit. Il explique les différents points à mettre en place pour améliorer la productivité d’une équipe. C’est presque la Bible du Désendetteur Technique non ?

Mais attendez… j’ai déjà vu cela quelque part.

Je vous demande un peu de concentration. Ouvrez cet article dans une autre page et lisez tranquillement « The Joel Test« .
Comme moi vous voyez les 12 points que nous connaissons tous un peu près non ?
Bon, et maintenant pouvez-vous s’il vous plaît, regarder à quelle date cet article a été publié ?

En août 2000… Mince ça fait mal non ?
Là vous vous dîtes juste que le bonhomme a écrit il y a 9 ans ce que l’on nous sert aujourd’hui comme de l’eau bénite ! Et c’est donc pour dire que les Désendetteurs Techniques sont des gars qui ont déjà lu tout cela, qui savent plus que vous ce qu’il faut faire. Ils sont capables d’identifier rapidement un gros souci dans votre projet. Que ce soit une architecture un peu pourrie, une librairie tordue, un réglage par défaut mal fait, c’est juste un gars qui sait ce que vous devriez savoir, et ce que vous saurez à terme. Ce bonhomme a juste un peu plus d’expérience et de culture que vous, il n’est pas plus intelligent que vous, il est juste plus instruit.

Oui vous savez maintenant qu’il faut faire de l’intégration continue. Si vous m’aviez contacté en février 2006 je vous aurai déjà parlé de CruiseControl car je m’amusais avec. Si vous me contactez maintenant, je vous parlerai d’Application Content Provider plutôt que de Portails et de CMS, car c’est un truc qui sera là dans quelques années. Notez la date de cette article, et on se revoit dans 4 ans. Suivez l’aventure d’eXo Platform, Benjamin Mestrallet parle d’Application Content Provider (voir aussi cet article). On en reparlera sur le blog.

Enfin si vous n’avez pas de Désendetteur Technique et que vous en cherchez un, il faut contacter les cabinets spécialisés dont la liste des Blogs est là, juste à gauche de cet article. OCTO Technology, Xebia, Oxiane, Ippon Technologies, SFEIR, Zenika, je crois que je connais au moins 3 ou 4 personnes dans chacune de ces entreprises. Et là vous pouvez vous dire que c’est bon signe. ll y a des gars comme moi, passionné qui pourront vous donner un coup de main. Il y a des Docteur House, des équipes de SOS Fantômes, des Men in Blacks, bref il y a de quoi venir remettre d’équerre soit votre code, soit votre équipe ou sinon votre projet.

Désendetteur Technique

Merci Dimitri.

Articles similaires:

EventStorming, technique de modélisation en équipe Architecture technique du CFP