Le côté obscur de la dette technique

Cet aspect du développement informatique peut parfois être mal maîtrisé et amener à une dette dont le concept va bien plus loin que le simple côté technique d’un projet.

Jean-Luc, rejoins le côté obscur de la dette…

Qu’est-ce qu’une dette technique ?

Si vous êtes déjà un fin connaisseur de la dette technique, je vous invite à sauter ce chapitre.

Ward Cunningham, auteur du concept de “dette technique” en 1992 était loin de s’imaginer que ce terme serait dans la bouche, voire pour certains dans les cauchemars, de beaucoup de personnes dans les entreprises de développement informatique.
Elle est définie par une ou plusieurs parties du code qui sont difficilement modifiables ou évolutives, voire plus utilisées. C’est donc l’effort restant à effectuer pour que le code livré soit d‘une qualité qu’une ou plusieurs personnes auront jugé comme acceptable pour le bon fonctionnement du projet ou pour sa maintenance. Ce concept s’appelle “dette technique” car il engendre généralement des coûts supplémentaires souvent conséquents et imprévus causés par l’aspect technique du projet.

La dette technique peut apparaître de plusieurs manières : volontairement ou non.

La dette volontaire

Elle peut être introduite par une équipe qui souhaite livrer un projet rapidement et qui décide de prendre des raccourcis en mettant de côté les normes et règles établies au préalable qui leur permettraient de mieux concevoir le projet. C’est souvent la conséquence d’une date de livraison trop courte, d’une mauvaise estimation du projet ou de demandes de dernière minute. Pour certaines entreprises ou pour certains projets cet aspect est tout à fait assumé car l’investissement pour maîtriser la dette est trop lourd comparé aux gains globaux du projet (ne générant que peu d’argent, par exemple). Il peut aussi arriver que la dette soit introduite par des développeurs qui ne saisissent pas les avantages à produire un code de qualité.

La dette involontaire

Elle est introduite de manière naturelle au cours du développement du projet. Soit à cause d’un manque d’expertise au niveau des bonnes pratiques de conception ou d’un manque de respect des normes, c’est ce qu’on appelle le “Code Smells” ; soit à cause d’un manque de recul de la part de l’équipe, ce qui amène souvent à remarquer la dette seulement à la livraison ou lorsque de nouvelles demandes arrivent et qu’il devient difficile de les implémenter.

Cette dette est souvent imputée aux développeurs, même si c’est le cas pour une bonne partie de celle-ci, il est important de comprendre qu’elle est introduite par toute l’équipe. Comme par le manager avec ses décisions souvent tournées autour du budget et ne souhaitant pas contrarier le client, ou par le Product Owner qui ne cadre pas assez correctement le projet dans le cas d’une organisation en mode agile, comme l’explique très bien Thiga dans cet article. Ou bien même par le client qui ne comprend pas pourquoi le projet a des estimations aussi longues et qui pousse parfois l’équipe à la faute.

Ce concept a été introduit pour l’informatique mais peut correspondre à d’autres domaines comme un boulanger demandant sans cesse à son apprenti d’aller plus vite pour respecter le quota. Cela a pour conséquences un pain d’une moindre qualité et des clients insatisfaits car l’apprenti a besoin de temps pour assimiler les gestes à faire pour produire du pain de la même qualité que l’artisan boulanger. A chaque domaine sa dette.
Dans l’informatique, nous mettons trop souvent en avant l’aspect technique de celle-ci, mais beaucoup de personnes oublient que la dette n’est pas seulement technique.


Une dette technique pas si technique que ça

Bien sûr, la dette est introduite par l’aspect technique du projet, mais au final celle-ci devient bien plus qu’une simple dette technique. Elle devient aussi une dette morale.

Le développeur, assez majoritairement, est une personne qui possède une certaine fierté, puisqu’il “créé” son propre code. Critiquer le code revient souvent à critiquer son créateur. Lorsqu’un développeur ne produit pas quelque chose dont il est fier, le moral a tendance à en pâtir. Bien sûr, certaines personnes sont moins sujettes à cet effet, mais il arrive tôt ou tard. C’est à ce moment que le rendement de l’équipe, ou la vélocité dans le cas d’un mode agile, commence à diminuer.

Il en devient même gênant lorsqu’une nouvelle personne intègre le projet ou l’entreprise et qu’il faut lui expliquer une partie du code qui possède une complexité technique très importante et qui rentre donc dans la dette technique. D’un côté, le développeur qui va expliquer le code va tourner autour du pot :

Alors alors… C’était avant tout pour palier à la demande urgente du client, parce qu’après tout, le client est roi. Et au final ça fonctionne pas trop mal non ? Au pire si t’as un ticket dessus, tu me le donnes. Bon, on t’a montré la cafet’ sinon ?

Et de l’autre côté, le développeur qui arrive sur le projet n’est pas dupe et se demande dans quoi il s’est mis.
Cela n’embarrasse pas seulement le développeur, mais aussi, par exemple, le manager qui souhaite recruter un nouveau développeur et qui va commencer à donner aux candidats des arguments suivis de “mais” un peu hasardeux : “nous avons des normes… mais parfois on les oublie un peu à la fin des projets”, tout cela pour justifier une dette technique parfois trop embarrassante.

D’autres facteurs externes peuvent amplifier la baisse de moral et donc augmenter une dette déjà ancrée, comme par exemple du matériel peu puissant où le développeur est obligé d’attendre de manière passive devant son écran, ce qui engendre une perte de temps importante comme le montre très bien cet article (notez la petite illustration en fin d’article, à mettre au goût du jour), ou encore un environnement de développeur qui n’est pas au point.

Autant de facteurs qui engendrent du stress et dans certains cas le “syndrome de l’imposteur” puisque le développeur remet en question son travail. Nous savons tous que le stress est contagieux même si certains diront :

Le stress c’est bien, ça améliore le rendement !

Pourtant c’est comme le cholestérol : il y a le bon et le mauvais. Pour le stress, c’est la même chose. Ici, c’est du mauvais stress : les développeurs s’étant fait à la dette, n’essayent même plus de la maîtriser voire se comparent aux autres projets de l’entreprise en se disant ô combien ils seraient heureux de changer de projet. Le Product Owner ne s’investit plus dans le projet et les méthodologies ou les bonnes pratiques ne sont plus respectées. Enfin, le manager qui ne sait plus quoi dire au client pour le calmer, ne cesse de reculer la date de livraison.

Bien sûr, le tableau dessiné ci-dessus est dans un cas avancé de la dette morale, mais celle-ci est souvent mise de côté au profit de la technique.

La dette morale fait parti de la dette technique, c’est un ensemble de dettes qu’il faut apprendre à maîtriser.

Reconnaître les signes de la dette technique

Il existe de nombreux signes qui montrent qu’une dette technique s’installe, que ce soit dans le code des développeurs ou bien dans le comportement de l’équipe.

Les signes liés au projet

  • Un rendement (ou vélocité) bien moindre : des livraisons de plus en plus longues ou possédant moins de fonctionnalités.
  • Des régressions à répétition.
  • Un code de plus en plus complexe et qui nécessite du reverse-engineering.
  • Dans le cas d’un mode agile, une note de rétrospective en déclin.
  • Du code dupliqué.
  • Peu ou pas de tests unitaires.

Les signes liés à l’équipe

  • Des développeurs qui ne souhaitent pas intervenir sur une fonctionnalité précise car trop complexe ou parce que ça risque “de casser si on y touche”.
  • Un développeur attitré à une fonctionnalité précise.
  • Des heures supplémentaires inhabituelles (même si elles ne devraient jamais être habituelles, mais c’est un autre sujet).
  • Le besoin ou la demande pour des outils de debuggage.
  • Des développeurs qui commencent à rajouter le terme “legacy” au nom du projet.

Cette liste est exhaustive et j’ai omis les demandes évidentes de refactoring, mais elle donne une bonne vision sur l’état de la dette technique au sein du projet.


Maîtriser la dette technique

Tout d’abord, la dette ne s’évite pas, elle se maîtrise. Comme expliqué ci-dessus, la dette peut être involontaire et naturelle dans le processus d’un projet. Cette maîtrise ne peut être effectuée seul, elle doit être maîtrisée en équipe : chaque développeur, Product Owner ou manager doit y mettre du sien pour y arriver. Il est logique que le niveau d’effort pour les développeurs soit plus important que pour le manager, mais la dette n’est pas seulement liée aux développements ni, encore une fois, à l’aspect technique du projet.

Les méthodes agiles

Si vous ne travaillez pas déjà avec une méthode agile, c’est un très bon moyen pour arriver à maîtriser la dette. Cela permet d’amener à la discussion avant les sprints (poker planning), pendant les sprints (daily-meeting) et après les sprints (rétrospective), en y incluant toute l’équipe. Le découpage en petites tâches aide aussi énormément : la complexité est plus facilement identifiable et permet d’éviter la dette involontaire.
Il faut bien comprendre que les méthodes agiles ne sont pas aussi simples que cela à maîtriser et leurs effets ne sont visibles qu’après plusieurs sprints, c’est un peu comme une série : il ne faut pas s’arrêter au premier épisode.

Il y a cependant certaines choses à ne pas faire en méthode agile, notamment dédier un sprint complet à du refactoring de code : aucune démo ne pourra être effectuée car il n’y aura rien de concret à montrer et le sprint va perdre tous les bénéfices d’une livraison. Même si la dette va chuter en flèche, cela nous ne jouera que très peu sur le moral de l’équipe car elle peut avoir l’impression de stagner ou pire, si au sprint suivant elle s’aperçoit que la dette n’a pas autant chuté qu’espéré, cela peut avoir l’effet inverse.
Préférez plutôt dédier un pourcentage de la vélocité à la maîtrise de la dette à chaque sprint : entre 10% et 30% de la vélocité selon le contexte, mais ne descendez jamais en-dessous de 10% car les développeurs ont un certain besoin de rendre la partie du code sur laquelle ils travaillent de meilleure qualité (la règle “Boy Scout”). Ils pourront ainsi choisir les tâches après chaque fin de poker planning et décider ensemble de ce qui serait le mieux pour le projet afin de diminuer la dette à un niveau raisonnable. Les tâches deviendront une ou plusieurs histoires utilisateurs (user stories) et feront parties intégrantes du sprint. Une démo entre développeurs peut même être organisée pour présenter les améliorations.

Il est important de donner un périmètre strict aux histoires utilisateurs : définissez au début du projet le moment où une histoire est jugée comme terminée (“Definition of done”) grâce à une simple liste à cocher. Mais attention à ne pas tricher : il peut être facile, par exemple, de créer une tâche de tests unitaires à faire pour plus tard et ainsi de passer l’histoire en “terminée”. Ceci ne doit pas être possible et c’est le rôle du Product Owner de ne pas laisser passer ce genre de détournement.

Se tenir informé de la dette

L’agilité ne fait pas tout, il faut que toute l’équipe soit au-courant de la dette technique, voire même les personnes externes au projet. Pour y arriver, vous pouvez lister les tâches faisant parties de la dette à chaque fin de sprint et les noter dans un tracker (Trello est un bon exemple). Il est important de prioriser la criticité de chaque tâche en donnant des points (de 1 à 100 par exemple, 1 étant faible et 100 critique) et d’en faire un graphique en additionnant tous les points pour avoir une vue d’ensemble mais surtout savoir si la dette a augmenté ou diminué (en bleu sur l’image ci-dessous). Vous pouvez ajouter un seuil critique à ne pas dépasser qui, par exemple, pourrait signifier que le bon développement du projet pourrait être fortement ralenti (en rouge) et qui, si celui-ci est dépassé, signalerait un investissement plus important à la maîtrise de la dette lors du prochain sprint pour la refaire passer sous le seuil critique.

Source : http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt

Comme l’a proposé Maxime Thoosen lors du forum PHP 2016, il est important qu’un référent soit assigné à chaque tâche, plus généralement celui qui l’a créé. Ce n’est pas forcément lui qui la corrigera, mais il pourra expliquer aux autres développeurs sa vision de la tâche et son apport dans la dette. La priorisation de la criticité des tâches de la dette technique doit être discuté en équipe, voici une liste en guise d’exemple :

  • Faille de sécurité
  • Complexité élevée
  • Couplage fort
  • Ne respecte pas les normes
  • Peu ou pas de documentation
  • Pas de test unitaire
  • Code dupliqué

Bien sûr, les éléments ci-dessus peuvent être cumulés et les points se retrouvent donc additionnés à la tâche liée. J’ai omis volontairement les points pour chaque élément car cela se décide avec toute l’équipe et peut varier selon le contexte du projet : des points peuvent être plus critiques que d’autres.

D’autres éléments pour maîtriser la dette technique

Les deux points ci-dessus sont les plus importants à mettre en place. Mais vous pouvez aller plus loin, voici quelques possibilités que vous pouvez appliquer pour maîtriser la dette :

  • Les développeurs étant flemmards pour la plupart, les tâches de la dette technique peuvent être automatisées dès qu’un “FIXME” apparaît dans le code. Grâce au versioning il sera aisé d’assigner un référent à la tâche.
  • De manière générale, privilégiez l’industrialisation des tâches répétitives : c’est un gain de temps sur la longueur et des erreurs humaines sont souvent évitées. Sans aller bien sûr dans l’excès
  • Faire du pair-programming est quelque chose de très enrichissant.
  • Tester chaque tâche de la dette technique avant la résolution pour éviter qu’elle ne réapparaisse.
  • Ne pas réinventer la roue : même si un développeur souhaite absolument se challenger en créant une partie du code, une communauté de plusieurs centaines/milliers de développeurs y arriveront forcément mieux.
  • Avoir une ou plusieurs personnes expertes dans leur domaine pour faire de la R&D, des stress tests, des Proofs of Concept, etc. sur des technologies inconnues ou peu maîtrisées permettant ainsi de réduire voire d’éviter les erreurs pendant la phase de développement.
  • Utiliser pour chaque tâche de la dette technique ou pour chaque problème rencontré, la “méthode des 5 pourquoi” qui permet de poser de manière répétitive des questions commençant par “Pourquoi” permettant de remonter jusqu’à la source du problème.
“Le système d’email peut être optimisé”
“Pourquoi ?”
“Parce que l’envoi de l’email bloque le chargement de la page”
“Pourquoi l’envoi bloque t-il le chargement de la page ?”
Parce qu’on l’envoie de manière synchrone
“Pourquoi est-ce qu’on l’envoie de cette manière ?”
Parce que notre gestionnaire de queue ne fonctionne plus

Vivre avec la dette technique

Une fois la dette technique maîtrisée, il devient plus simple de vivre avec.
Attention cependant à ne pas vouloir à tout prix la supprimer. C’est comme le test coverage, avoir du 100% est utopique et n’est pas forcément signe de bonne santé du code. L’investissement peut être trop important comparé aux retours sur l’équipe et ne veut pas forcément dire que le projet se passe bien : maintenez-la à un niveau raisonnable.

Il y a certaines règles à appliquer pour que la vie commune soit plus aisée :

  • Ne plus en faire un tabou : la dette technique doit être visible de tous et surtout discuté avec tout le monde, y compris les personnes externes qui ont un recul que vous n’aurez certainement plus sur votre projet passé un certain temps.
  • Discutez-en toujours en équipe, une personne seule n’est pas toujours apte à décider de la criticité ou de la résolution d’une tâche de la dette technique.
  • Refactoriser du code est souvent vu comme de la sur-qualité voire de l’acharnement à avoir un code propre. Mais il faut bien comprendre que c’est une amélioration de la maintenabilité du code, et donc de la délivrabilité du projet.
  • Célébrez les bugs ou les tâches de la dette technique les plus farfelus. Etsy, par exemple, après un déploiement sur le système de police d’écriture, s’est vu affublé d’un emoji de cheval collé à la 5ème étoile du système de note. L’équipe a souhaité décorer les bureaux en interne tellement le bug était improbable (cf. image ci-dessous).
Lara Hogan, “Engineering Director” à Etsy

Le bon côté des choses

Vivre avec la dette technique peut aussi avoir un bon côté : cela met le développeur face à ses erreurs et lui rappelle qu’il est normal d’en faire. Le code n’est donc plus quelque chose d’acquis et cela le poussera à se poser les bonnes questions lors de la conception de celui-ci.