desendeteur

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.

9 réflexions sur « Désendetteur Technique »

  1. Bonjour

    Peux-tu développer en quelques mots ce que tu appelles « un application content provider »? Dans l’article que tu mentionnes sur exo, je n’ai rien trouvé sur le sujet.

  2. Tant qu’on es dans les jeux de mots:
    – on utilise aussi parfois un huissier de Guice-stice
    – Agile enables micro-credit not toxic debts
    Sonar a un module de dette technique très bien fait. En dollar ca impressionne toujours plus.

  3. Est-ce qu’en parrallèle des opérations one-shot du Désendetteur Technique ceux-ci maintiennent une activité plus classique du développement logiciel (bosser plusieurs mois sur un projet) pour rester près des réalités et connaître réellement les conséquences d’un choix lors d’une intervention? En effet le Désenteur Technique prodigue des conseils mais ce n’est pas lui qui va devoir faire avec au quotidien.

    Autre point qui caractérise les Désendetteur Technique, ils ont une plus grande propension à avoir un blog.

  4. @William : article prévu sur ce sujet d’ici 2 semaines. Je bosse dessus, je vais passer 2 jours avec eXo cette semaine.

    @Niala78 : tu as raison, il ne faut pas tomber dans le travers du Consultant qui conseille sans avoir jamais avoir fait ou pratiqué soit-même…

  5. Pourquoi ton post est-il dans la catégorie « humour » ?

    C’est important d’avoir dans toutes les équipes un désendetteur qui passe de temps en temps pour pallier aux petites entorses aux bonnes pratiques pour les équipes sénior et aux grands écarts des équipes débutantes.

    « Cut 1/4 of your features, problem because 1/2 as hard to solve » (Greg wilson, Slide #5 http://bit.ly/2Ixihm) car
    « For every 25% increase in problem complexity, there is a 100% increase in solution complexity (woodfield ’79 http://bit.ly/2KAJMs) »
    Ces citations me semblent être l’essence même de la différence entre les équipes qui fonctionnent et celles qui rament.

    Le désendetteur doit autant simplifier les chemins techniques empruntés, intégrer les bons outils, les bonnes méthodologies que savoir reposer les problèmes pour simplifier les développements de façon drastique.

  6. Article sympa, même si je ne suis pas trop d’accord avec la formule « Faire du Scrum, c’est faire un saut de 10 mètres dans le vide ». Je pense qu’au contraire on fera mieux faire évoluer les mentalités d’une équipe et surtout des responsables en grimpant une marche après l’autre, plutôt que vouloir faire tout l’escalier d’un coup.
    Mais ça, c’est plutôt le « comment » que le « quoi » dont il est plutôt question dans cet article.

Les commentaires sont fermés.