Nettoyage du code

Utilisation de techniques Agile pour rembourser la dette technique

David Laribee

Dans chaque base de code se cachent des zones d'ombre que vous craignez. Du code qui est incroyablement fragile ; du code qui génère des bogues de régression ; du code incompréhensible à vous rendre fou.

Ward Cunningham emploie une jolie métaphore pour parler des parties du code difficiles à changer ou sujettes à l'erreur en les comparant à une dette financière. La dette technique vous empêche d'avancer, de gagner de l'argent, de rester créditeur. Comme dans le monde réel, il existe une dette bon marché, une dette avec un taux d'intérêt inférieur à celui que vous pouvez obtenir dans un instrument financier à faible risque. Mais il y a aussi la dette qui coûte cher, les cartes de crédit à taux d'intérêt élevé qui génèrent encore plus de dettes.

La dette technique est un véritable fléau. Elle peut anéantir la productivité en rendant la maintenance pénible, difficile, voire impossible. Au-delà de l'impact économique évident, la dette technique a un véritable coût psychologique. Quel développeur aime s'asseoir le matin devant son ordinateur sachant qu'il va bientôt se trouver face à du code source incroyablement fragile et compliqué ? Les sentiments de frustration et d'impuissance que cela engendre sont souvent la cause profonde de problèmes plus systémiques comme le renouvellement des développeurs, qui n'est que l'un des coûts économiques réels de la dette technique.

Toutes les bases de code sur lesquelles j'ai travaillé ou que j'ai corrigées contiennent une dette technique plus ou moins importante. Il existe un type de dette pratiquement inoffensif : les dépendances byzantines entre des types aux noms étranges dans des recoins stables et rarement modifiés de votre système. Ou encore le code peu soigné qui peut facilement être corrigé sur le vif, mais qui est souvent ignoré dans l'urgence de résoudre des problèmes prioritaires. Les exemples ne manquent pas. 

Cet article présente un workflow et différentes tactiques permettant de traiter la dette qui coûte cher. Les processus et les pratiques que je vais décrire ne sont pas nouveaux. Ils sont directement tirés du manifeste Lean/Agile.

Arguments en faveur de la correction de la dette

Dans mon livre, la question de savoir si la dette technique doit être corrigée ne se pose même pas. Bien sûr qu'elle doit l'être. La dette technique dessert vos objectifs car elle vous ralentit au fil du temps. La courbe très connue de coût des modifications (voir Figure 1) illustre la différence entre l'approche guidée à 100 % par des tests de qualité et l'approche du cowboy codeur qui bâcle son code.

Figure 1 Courbe de coût des modifications

La courbe de coût des modifications illustre le fait que les conceptions de code de grande qualité, simples et faciles à utiliser peuvent initialement coûter plus cher, mais induisent une dette technique inférieure, ce qui fait que les ajouts et les modifications apportés ultérieurement au code sont moins coûteux au fil du temps. La courbe de qualité (en bleu) montre que le coût initial est plus élevé, mais qu'il est prévisible dans le temps. La courbe de « bâclage » (en rouge) montre un coût d'entrée plus faible, mais le développement futur, la maintenance et le coût total de possession d'un produit et de son code finissent toujours par revenir plus chers.

Dans sa première loi sur la programmation (c2.com/cgi-bin/wiki?FirstLawOfProgramming), Ward Cunningham déclare que la baisse de la qualité allonge le temps de développement.

« Un logiciel de qualité est le moins long à développer. Si votre code est simplifié au maximum, qu'il est testé et que sa conception répond exactement aux besoins, les ajouts et les modifications sont très rapides car leur impact est moindre. Par conséquent, plus vous bâclez votre code, plus vous allez lentement car le coût des ajouts ou des modifications s'accroît avec chaque ligne de code. »

Pour faire simple, la dette technique réduira les performances de votre équipe au fil du temps.

L'une de mes grandes joies dans le développement logiciel est de savourer le sentiment de productivité brute. Le sentiment de compétition et de contradiction est, du moins pour moi, une plaie. C'est douloureux lorsque je ne suis pas productif et c'est la douleur qui me prive de ma productivité potentielle les soi-disant « bonnes journées de travail ». Le développement logiciel est source de nombreuses douleurs, mais aucune aussi évidente qu'une base de code rigide et chaotique. Cet effet psychologique sape le moral des équipes et finit par ralentir la productivité.

La pensée systémique

Pour corriger la dette technique, vous devez cultiver l'engagement des parties prenantes comme des coéquipiers. Pour cela, vous devez commencer à penser système. La pensée systémique est une pensée à long terme. C'est penser en terme d'investissement. C'est l'idée que l'effort que vous consentez aujourd'hui vous permettra de progresser à une allure prévisible et soutenue dans le futur.

Peut-être est-il plus facile d'expliquer la pensée systémique par une analogie. J'habite dans le centre d'Atlanta en Géorgie, dans un petit quartier pittoresque nommé Inman Park. Je suis globalement très heureux ici. Je réserve toutefois quelque irritation face à l'ignorance apparemment totale de la planification urbaine. Les rues d'Atlanta sont un véritable labyrinthe à vous rendre fou. Malheur à vous si vous manquez la rue où vous devez tourner car vous ne pourrez pas tout simplement faire demi-tour. Et si vous le faites, vous vous retrouvez pris dans une spirale vous menant Dieu ne sait où. Cet agencement des rues n'a aucun sens dans ce petit coin, par ailleurs plaisant, du monde.

Comparez-les aux rues et aux avenues bien ordonnées de Manhattan à New York (la plupart en tout cas). On croirait qu'un instructeur du corps des marines américains a dessiné la ville. Les avenues s'étendent sur toute la longueur de l'île, du nord au sud, et les rues forment des repères transversaux clairs. De plus, les rues et les avenues sont nommées selon une séquence numérique : Première avenue, Deuxième avenue, 42ème rue, 43ème rue, etc. Vous marcherez rarement plus d'un bloc dans la mauvaise direction.

Quelles sont les causes profondes de cette différence entre Atlanta et New York ?

À Atlanta, les rues ont été formées par le bétail qui a tracé des chemins. Vous m'avez bien entendu, les chemins tracés par le bétail. À une époque, les déplacements fréquents entre le centre urbain et la banlieue sont devenus nécessaires. C'est alors qu'un cowboy a dû se dire : « ma foi, ce ne serait pas plus simple de transformer les chemins existants tracés par le bétail en routes ? ».

La législature de l'État de New York a appliqué une vision et a fait preuve de prévoyance dans la conception de la ville la plus grande de l'État qui ne cesse de grandir. Elle a choisi un plan en quadrillage avec des rues est des avenues ordonnées et logiques. Elle a pensé au futur.

Cette histoire est l'essence même de la pensée systémique. Bien que les processus législatifs soient lents, l'investissement en temps et l'attachement à une vision génèrent les plus gros dividendes sur la durée de vie d'un système. Certes, il faudra composer avec les taxis fous dans les rues principales de Manhattan, mais vous pourrez vous repérer en quelques jours. À Atlanta, je me suis perdu pendant une année entière et je remercie chaque jour les penseurs systémiques qui sont à l'origine du GPS.

Les produits avant les projets

L'idée qu'une équipe de développement réalise un projet puis s'en décharge sur une équipe de maintenance est une profonde hérésie. Ne vous y trompez pas, vous travaillez sur un produit et s'il rencontre le succès, il va vivre très très longtemps.

Si vous n'avez ne serait-ce que quelques années d'expérience en tant que développeur professionnel, vous avez certainement noté l'effet de gravité croissant. Vous développez un morceau de logiciel qui n'est pas censé durer, ne pas être compliqué ni même être modifié. Et six mois plus tard, que faites-vous ? Vous le modifiez ? Vous l'enrichissez ? Vous corrigez des bogues ?

Pour peu qu'ils soient utiles, les logiciels ont parfois la fâcheuse tendance à rester dans les parages très longtemps. C'est à vous de choisir la métaphore qui vous guidera. Allez-vous prendre soin d'une forêt de magnifiques séquoias californiens, ces entités vivantes traversant les siècles et atteignant des hauteurs extraordinaires ou allez-vous laisser de pauvres fougères envahissantes priver votre forêt de lumière ?

Workflow de base

À ce stade, j'espère vous avoir convaincu que la dette technique peut avoir un effet désastreux sur votre santé mentale et sur le prix à payer par vos clients. J'espère également que vous adhérez à la nécessité d'avoir une vision à plus long terme sur les produits que vous créez.

Voyons maintenant comment vous pouvez vous sortir de ce trou.

Quel que soit ce que vous faites, je pense que le workflow de base pour s'attaquer à la dette technique - en fait à toute amélioration - est répétable. En gros, vous voulez faire quatre choses :

1. Identifier où vous avez une dette. Dans quelle mesure chaque élément de dette affecte les résultats de votre entreprise et la productivité de votre équipe ?
2. Monter une étude de faisabilité et obtenir un consensus sur la priorité avec les personnes affectées par la dette (à la fois l'équipe et les parties prenantes).
3. Corriger la dette que vous avez choisie avec des tactiques qui ont fait leur preuve.
4. Recommencer. Revenir à l'étape 1 pour identifier une autre dette et poursuivre les améliorations que vous avez apportées.

Pour le processus de développement logiciel qui nous intéresse ici, il est important de mentionner que ce workflow est adapté de l'approche de management nommée la Théorie des contraintes (Theory of Constraints - ToC) pensée par Eliyahu Goldratt (goldrattconsulting.com). La Théorie des contraintes est un modèle de pensée systémique proposant un cadre pour améliorer la performance globale du système. C'est là une définition largement simplifiée, mais cette théorie repose sur l'idée qu'un système (une usine de fabrication, par exemple) ne peut pas être plus productif que son plus gros goulet d'étranglement. La valeur, telle qu'une fonctionnalité demandée, une voiture ou tout élément commercialisable, est imaginée, conçue, produite et déployée. Une fonctionnalité peut être demandée par un client, interne ou externe et suit alors les méandres de votre société (le système) en se transformant peu à peu d'une idée en résultat tangible. Que se passe-t-il lorsque ces fonctionnalités s'entassent sur les bureaux de votre équipe d'assurance qualité ? Que se passe-t-il lorsque les demandes dépassent la capacité d'une équipe de développement ? Vous avez un goulet d'étranglement et le système entier ralentit.

Votre base de code contient très probablement de nombreuses zones de dette ou goulets d'étranglement. Identifier la dette qui vous ralentit le plus aura l'effet net le plus important sur l'amélioration de votre performance. Comprendre, puis s'attaquer à la dette et obtenir des améliorations en tant qu'équipe, en tant que système, est le meilleur moyen d'apporter des changements positifs car plus de mains et d'yeux sur le code signifient moins de risques et de meilleures conceptions.

Identifier les zones de dette

Il est important que vous soyez capable de pointer du doigt les zones posant problème. Si vous ne les avez pas recensées dans un wiki, dans une liste partagée ou dans des commentaires attachés à votre code, votre première tâche est de trouver la dette.

Si vous travaillez au sein d'une équipe, je vous suggère d'organiser une réunion afin de dresser une liste concrète des principales zones de dette dans votre code. Il n'est pas important que cette liste soit exhaustive. Concentrez-vous sur le recensement des éléments coûteux. Cette réunion est votre première opportunité, en tant que leader dans votre équipe, de commencer à forger un consensus. Plus de la majorité simple des membres doit être d'accord et comprendre un élément pour l'ajouter à la liste.

Une fois la liste dressée, rendez-la pérenne. Créez une rubrique wiki, écrivez-la sur un tableau blanc (avec la mention « NE PAS EFFACER » en évidence dans un coin) ou utilisez tout autre moyen qui peut marcher dans votre contexte. Le support que vous choisissez doit être visible, permanent et facile à utiliser. Vous devez l'avoir devant vous régulièrement. Vous devez revenir à cette liste et la peaufiner. Les êtres humains ont une mémoire à court terme limitée. Je vous suggère donc de restreindre la liste à 5 à 9 éléments. N'essayez pas à tout prix de dresser un inventaire : les éléments importants referont surface s'ils sont réellement importants.

Utilisation de métriques pour identifier les zones posant problème

Il est parfois difficile d'identifier la dette, tout particulièrement si une équipe travaille depuis peu sur une base de code. En l'absence de mémoire collective ou de tradition orale sur laquelle s'appuyer, vous pouvez utiliser un outil d'analyse statique comme NDepend (ndepend.com) pour tester les parties du code les plus délicates.

Au mieux ces outils sont une assistance, voire un second choix. Mais ils ne vous diront jamais quoi faire. Ils vous donneront des éléments de réflexion pour prendre vos décisions. Il n'existe pas une métrique spéciale pour la dette de code, mais les personnes qui travaillent jour et nuit sur un produit peuvent sans nul doute pointer du doigt les zones d'ombre à l'origine des plus grands maux. Les outils d'analyse statique vous diront où vous avez une dette d'implémentation. Malheureusement, ils ne vous diront pas où vous avez une dette en raison de facteurs comme une dénomination, une capacité de découverte ou des performances de mauvaise qualité ou d'autres considérations de conception et d'architecture plus qualitatifs.

La connaissance de votre couverture de test (si vous utilisez des tests) peut également s'avérer un outil précieux pour découvrir la dette cachée. En effet, si une grande partie de votre système n'est pas testée en profondeur, comment pouvez-vous être certain qu'une modification n'aura pas des effets désastreux sur la qualité de votre prochaine version ? Des bogues de régression risquent de se produire, créant des goulets d'étranglement pour le contrôle qualité et potentiellement des ennuis et des pertes de revenus en raison des défauts trouvés par les clients.

Utilisez la fonctionnalité de journalisation de votre système de contrôle de version pour générer un rapport des modifications apportées au cours des un ou deux derniers mois. Identifiez les parties de votre système faisant l'objet de plus d'activité, de modifications, d'ajouts et examinez-les pour identifier la dette technique. Cela vous aidera à identifier les goulets d'étranglement qui sont votre défi actuel. Il ne sert pas à grand-chose de corriger la dette des parties de votre système rarement modifiées.

Goulets d'étranglement humains

Si un seul développeur est capable de traiter un composant, un sous-système ou une application entière, vous risquez de vous retrouver avec un goulet d'étranglement. L'appropriation individuelle du code et les silos de connaissance peuvent bloquer la livraison si cette personne quitte l'équipe ou a une tonne d'autres choses à faire. En identifiant les parties de votre projet dont une seule personne est maîtresse, vous pourrez évaluer les avantages et la portée des améliorations apportées à la conception afin que d'autres individus partagent la charge. Éliminez le goulet d'étranglement.

Les avantages découlant de la pratique eXtreme Programming relative à l'appropriation collective (extremeprogramming.org/rules/collective.html) sont extraordinaires. « Avec l'appropriation collective, tout développeur de votre équipe est autorisé à modifier toute portion du code de votre base de code pour ajouter des fonctionnalités, résoudre des bogues, améliorer les conceptions ou remanier le code. Personne n'est à elle seule un goulet d'étranglement pour les changements ».

Ah ! Encore cette notion de goulet d'étranglement. En mettant en œuvre l'appropriation collective, il n'existe plus de zones d'ombre dans votre système que seul un programmeur, qui peut être amené à quitter son travail ou avoir un accident, connaît. Une base de code gérée collectivement est moins risquée.

D'après mon expérience, la conception est également bien meilleure. Deux, trois voire quatre têtes valent sans nul doute mieux qu'une seule. Dans une base de code gérée collectivement, un esprit d'équipe émerge et supplante les particularismes et excentricités individuels.

J'appelle l'appropriation collective de code une pratique, mais il s'agit véritablement d'une propriété émergente d'une équipe performante. Demandez-vous combien d'entre vous interviennent et travaillent sur votre code par rapport à un code partagé par une équipe entière ? Dans le domaine du développement logiciel, ce que l'on désigne par équipe correspond à de véritables groupes de travail avec un responsable de mission, dans lesquels les tâches de programmation sont distribuées en fonction de qui a travaillé sur une fonctionnalité, un sous-système ou un module particulier par le passé.

Misez sur l'équipe

J'ai dit précédemment qu'il était important d'impliquer toute l'équipe dans la dynamique d'amélioration. En tant que coach Agile, je suis scrupuleusement le mantra selon lequel les individus soutiennent un monde qu'ils contribuent à créer. Si vous n'obtenez pas le soutien du plus grand nombre, tout effort pour promouvoir la culture de l'amélioration continue peut être difficile à faire émerger, et encore plus à maintenir.

Il est primordial d'obtenir le consensus. La majorité des membres de l'équipe doivent soutenir l'initiative d'amélioration que vous avez choisie. J'ai utilisé avec succès l'approche de Luke Hohmann nommée Acheter une fonctionnalité (Buy a feature) présentée dans son livre Innovation Games (innovationgames.com). Je vais essayer de simplifier au maximum ce jeu et vous demanderai de vous reporter au livre si vous pensez que cela pourrait fonctionner dans votre environnement.

1. Dressez une brève liste (5 à 9 éléments) des points que vous voulez améliorer. Ces éléments sont idéalement envisageables à court terme.
2. Précisez pour chaque élément sa difficulté. J'aime pour cela utiliser la notion abstraite des tailles de T-shirt : petit, moyen, grand ou très grand (voir l'encart Estimation des opportunités d'amélioration pour plus d'informations sur cette pratique).
3. Attribuez un prix à chaque fonctionnalité en fonction de sa taille. Par exemple, les éléments de petite taille peuvent coûter 50 $, les éléments de taille moyenne 100, etc.
4. Donnez à chacun une somme d'argent. Le but ici est d'introduire dans le jeu la notion de manque. Vous voulez que les individus aient à réunir leur argent pour acheter les fonctionnalités qui les intéressent. Vous voulez fixer un prix pour les fonctionnalités de taille moyenne de sorte que les utilisateurs ne puissent pas les acheter individuellement. Il est intéressant de découvrir là où plus d'un individu voit une priorité puisque vous essayez d'obtenir un consensus.
5. Faites une partie courte, d'une durée de 20 à 30 minutes, pendant laquelle les individus peuvent discuter, conclure des ententes et défendre leur position. Ce jeu peut être très chaotique mais aussi très drôle et vous verrez où se trouvent les foyers d'influence dans votre équipe.
6. Passez en revue les éléments qui ont été achetés et avec quelle marge. Vous pouvez classer la liste en fonction des fonctionnalités achetées ou encore mieux utiliser les résultats du jeu Acheter une fonctionnalité en combinaison avec d'autres techniques, comme une perception du prochain plan de mise en production.

Estimation des opportunités d'amélioration

J'ai indiqué estimer les éléments de dette ou les opportunités d'amélioration en terme de taille de T-shirt. Cette technique est communément utilisée dans les méthodologies de développement Agile. L'idée est que vous collectez les éléments en termes de taille relative. Les éléments de petite taille vont ensemble, comme ceux de taille moyenne, de grande taille, etc.

Il n'est pas primordial que vous soyez extrêmement précis dans l'attribution des tailles. Rappelez-vous : il s'agit de mesures relatives et non d'engagements. Vous voulez avoir une idée globale de la difficulté, et la théorie veut qu'une fois le nombre d'éléments estimé, tout commencera à s'égaliser. Même si un élément de taille moyenne occupe deux développeurs pendant deux semaines alors qu'une autre tâche prend un mois, en moyenne, un élément de taille moyenne prend environ trois semaines.

Toutefois, au fil du temps, vous recueillerez des exemples de ce que sont vraiment des éléments de grande taille et de petit taille et cela vous aidera dans les estimations futures car vous aurez une base de comparaison. J'ai utilisé plusieurs exemples des différentes tailles par le passé pour m'aider à estimer un nouveau travail et le résultat était bon.

La pilule peut être dure à avaler pour les dirigeants. Ils voudront savoir d'emblée exactement combien de temps il vous faudra pour obtenir ce qu'ils souhaitent et pour vous dire la vérité, vous devrez peut-être investir du temps supplémentaire pour aboutir à une estimation précise dans le temps.

Vendez le projet

Une fois le projet en main, c'est le moment de communiquer sur l'intérêt de supprimer la dette auprès des promoteurs. En réalité, cette étape peut intervenir en parallèle de l'identification. Impliquez votre client dès le tout début. Après tout, le développement du projet demandera du temps, des efforts mais aussi de l'argent. Vous voulez à tout prix éviter les questions sur le temps et l'argent de qui vous avez dépensé pour développer un projet cohésif.

Le succès de votre démarche à long terme de réduction drastique de la dette requiert absolument le soutien des financiers et des promoteurs de votre projet. Ceux qui signent les chèques doivent comprendre l'investissement que vous faites. Cela peut être un véritable défi : vous demandez aux gens de penser à long terme, au futur et de se départir de l'état d'esprit de l'achat immédiat et du paiement ultérieur. Le simple « parce que » ne suffit pas comme explication.

Le problème est que les dirigeants ne manqueront pas de vous demander « Vous êtes des professionnels ? ». Vous vous sentirez parfois bafoué. Après tout, ne vous payaient-ils pas vous, le pro, pour livrer un produit de qualité à l'heure et dans le respect du budget ?

Cet argument peut être difficilement contré. Ne vous tracassez pas. Ayez le courage et l'honnêteté de présenter les faits tels qu'ils sont. Cette approche apparemment risquée n'est qu'une question de responsabilité et de confiance.

Formulez votre argument comme ceci : vous avez livré un logiciel qui fonctionne, dans le temps imparti et dans le budget alloué. Pour arriver à cela, vous avez dû faire en chemin des compromis en réponse à la pression. Maintenant, pour avancer à une allure prévisible et stable, vous devez vous pencher sur les effets de ces compromis. L'organisation entière les a achetés, il est maintenant temps de rembourser.

L'autre défi est de montrer à des personnes sans bagage technique là où la dette cause le plus de dommages. D'après mon expérience, les dirigeants répondent à des arguments quantitatifs reposant sur des données supportés par des « nombres » et des « faits ». Je place ces mots entre guillemets car nous savons tous que nous vivons dans un monde relatif et qu'aucun chiffre à lui seul (complexité cyclomatique, couplage efférent, ligne de code, couverture de test, etc.) ne permet de vendre un changement. Pour rajouter à la difficulté, vous devrez communiquer les zones enregistrant les plus grosses pertes du point de vue économique : pourquoi est-ce plus lent que vous le souhaiteriez ; pourquoi cette fonctionnalité a-t-elle coûté si cher ?

« Evidence DEFEATS Doubt » ou la preuve vient à bout du doute

Lors du montage de votre projet, vous pourrez utiliser un outil extrêmement utile tiré du système de formation en management de Dale Carnegie qui est compris dans une phrase toute simple « evidence defeats doubt ». Comme souvent avec les systèmes de management (et notre discipline d'une manière générale), le terme DEFEATS est un acronyme. Je vais expliquer quelques-unes des ses applications dans le développement logiciel. Notez toutefois que j'ai omis le second E qui signifie Exposer car il semble répéter le premier E, pour Exemple.

D pour Démonstration. Il n'y a rien de mieux que montrer en expliquant. C'est cela la démonstration. Si vous suivez votre rapidité, cela devrait être facile. Montrez la baisse au fil du temps (voir Figure 2) toute en établissant la connexion avec le code de plus en plus rigide et difficile à modifier. Une fois la vente amorcée, vous devez la poursuivre.

Figure 2 Suivi de la rapidité de développement

Si vous utilisez un processus Agile comme Scrum ou eXtreme Programming, les événements de commentaires des utilisateurs sont une pratique essentielle. À l'issue d'une itération, faites la démonstration des nouvelles fonctionnalités à votre client. D'un côté, montrez que la quantité et la qualité des fonctionnalités baissera lorsque vous vous heurterez à la dette technique et d'un autre, montrez les gains obtenus au fil du temps avec la montée en puissance de vos efforts d'amélioration. Moins de dette signifie de meilleurs résultats et de meilleurs résultats donnent davantage d'éléments à démontrer.

Avant de critiquer quelqu'un, essaie de te mettre à sa place, a-t-on coutume de dire. Si votre dirigeant est plus technique, encouragez-le à travailler avec les développeurs sur l'une des parties les plus ardues de la base de code pour qu'il adhère au principe que le changement est difficile. Demandez-lui d'examiner une partie du code. Arrive-t-il à suivre ? Est-ce lisible ? Il n'y a pas d'autres moyens d'atteindre votre but.

E pour Exemple. Rien ne vaut un exemple concret. Trouvez des scénarios ou des exigences qui n'ont pu être réalisés en raison de la dette technique ou qui ont créé une régression importante. Prenez une section de code illisible, byzantine, truffée d'effets secondaires. Expliquez comment ces attributs du code ont conduit le client à identifier un défaut ou ont nécessité un énorme effort de la part du contrôle qualité.

Les processus Agil mettent à votre disposition un autre outil puissant. Il s'agit de la rétrospective. Choisissez un scénario qui s'est dégradé dans les deux dernières itérations et posez la question « pourquoi ? ». Arrivez à la cause profonde expliquant pourquoi ce scénario particulier n'a pu être réalisé, a pris deux fois plus de temps que votre scénario moyen ou a nécessité plus d'une itération. Un logiciel rigide sera souvent le coupable ou peut-être avez-vous dû annuler les modifications car les bogues de régression étaient insurmontables. S'il s'avère que le dernier pourquoi est une raison liée à la dette technique, faites-en une analyse brève et concise. Vous avez là une autre corde à votre arc, un autre point dans votre argumentaire.

F pour Faits. Les faits sont très faciles à rassembler. Avez-vous livré un projet en temps voulu ? Quel était le taux de défauts après publication ? Quelle est la rapidité moyenne de l'équipe au fil du temps ? Les clients étaient-ils satisfaits du logiciel fourni ? Voilà le genre de faits que vous voudrez mettre en avant et je pense que ce sont ces faits qui sont les plus parlants pour les dirigeants.

La collaboration est un élément clé. En tant que développeur, vous pouvez plus facilement fournir des faits techniques. Cherchez de l'aide auprès de ceux qui tiennent les cordons de la bourse. Il y a des chances qu'ils aient une image beaucoup plus claire et un accès plus facile aux faits directement liés au business qui montrent les dommages causés par la dette technique.

A pour Analogie. Ce point est pour moi particulièrement important. Les hommes d'affaires trouvent parfois le développement logiciel déroutant, voir ésotérique. Si vous parlez à vos promoteurs de couplage et de cohésion ou encore du Principe de la responsabilité unique, il y a de grandes chances que vous les perdiez. Pourtant il s'agit là de concepts très importants dans le développement logiciel et au final, c'est de cette manière que vous préparez un projet piloté par les données pour résoudre la dette. Je vous suggère d'éviter le jargon et d'expliquer ces notions par une analogie.

Vous pouvez décrire le couplage comme un château de cartes par exemple. Dites à vos promoteurs que si votre rapidité a chuté c'est parce que modifier le code s'apparente à ajouter un mur, un toit ou un étage à une château de cartes déjà construit et très élaboré : une opération chirurgicale nécessitant une main exceptionnellement stable, beaucoup de temps et de patience, mais qui finalement est un événement incertain et source d'angoisse. Parfois le château de cartes s'effondre.

Lorsque vous utilisez des métaphores et des comparaisons, il est judicieux de le spécifier. Justifiez votre analogie par une brève description plus technique du concept que vous essayez de faire passer. Pour reprendre l'exemple du château de cartes, vous pouvez dire « c'est l'effet qu'a le couplage sur notre capacité à répondre aux changements et à ajouter de nouvelles fonctionnalités ».

T pour Témoignage. Entendre le même message par un tiers peut parfois avoir un effet très positif. Ce tiers peut être un leader du secteur ou un consultant. La raison pour laquelle ses mots peuvent avoir un plus fort impact que les vôtres est qu'il est considéré comme un expert objectif.

Si vous n'avez pas les moyens de vous offrir un consultant, rassemblez des anecdotes et des idées livrées gratuitement par les plus grands leaders du secteur. Même si les témoignages génériques sur les fameuses bonnes pratiques ne permettront sans doute pas de sceller l'accord, ils s'ajouteront à votre argumentaire global.

S pour Statistiques. Les nombres sont importants. Une phrase revient souvent en management : « si vous ne pouvez pas le mesurer, vous ne pouvez pas le gérer ». Je ne suis pas certain que cette croyance conventionnelle s'applique complètement, même vous pouvez certainement présenter quelque chose dans ce sens. Le couplage et la complexité sont deux métriques permettant de montrer une relation de cause profonde entre une baisse de performance (la quantité de travail livrée) et une base de code de plus en plus calcifiée par la dette.

Je trouve que les statistiques composites sont ce qui convient le mieux ici. Il est beaucoup plus facile de comprendre l'importance de la couverture de code si vous pouvez superposer une métrique de couverture de code qui baisse avec le temps avec une baisse de la rapidité, ce qui implique, à défaut de le montrer, une relation.

Nommez un leader

Vos efforts visant à obtenir le feu vert pour résoudre la dette technique iront beaucoup plus loin avec un véritable leader, un champion qui peut communiquer en termes business et qui a de l'influence sur les décisionnaires de votre organisation. Il s'agira souvent de votre chef, son directeur, le directeur de la technologie ou toute autre personne à l'autorité perçue similaire.

Ceci soulève l'intéressant problème de l'œuf et de la poule. Comment vendre cette personne ? Le processus de management vers le haut est également la responsabilité du développeur. Votre premier défi est de vendre le vendeur. Comment faire cela ? La preuve vient à bout du doute !

Étapes suivantes

Pour l'instant, je me suis penché sur l'identification de la dette en tant qu'équipe et sur le montage d'un projet pour corriger cette dette. Je vais me répéter : le consensus au sein de votre équipe et l'engagement auprès de vos clients sont les facteurs clés.

Faites en sorte que les étapes soient courtes et n'investissez pas beaucoup de temps. La première fois que vous identifierez une dette, cela prendra nécessairement plus de temps que lorsque vous itérerez sur de nouvelles opportunités d'amélioration. Mais lorsque vous montez votre projet pour les dirigeants, n'incluez que les éléments sur lesquels vous envisagez de travailler. Garder un œil sur la productivité peut vous faire économiser beaucoup d'énergie.

Dans un prochain numéro, j'examinerai le reste du workflow, notamment des tactiques permettant de supprimer la dette. J'expliquerai comme rendre ce processus itératif et comment tirer les leçons de précédents efforts pour supprimer la dette.

Dave Laribee dirige l'équipe de développement produit chez VersionOne. Il intervient régulièrement dans les événements locaux et nationaux destinés aux développeurs et a reçu le prix Microsoft Architecture MVP en 2007 et 2008. Il écrit sur le réseau de blog CodeBetter à l'adresse thebeelog.com.

Je remercie Donald Belcham, expert technique, d'avoir relu cet article.