The Four Grades of Technical Debt

http://madebymany.com/blog/the-four-grades-of-technical-debt par James Higgs

Presque toutes les communications entre les développeurs et collègues non techniques ou clients sont composées d’un jeu de métaphores. Certaines d’entre elles (la métaphore du bâtiment, par exemple) sont activement nuisibles, mais d’autres sont potentiellement très utiles.

L’idée de Dette technique est l’une de celles-ci, mais, comme avec toute métaphore, il est important de comprendre où se trouvent les limites de son applicabilité. Pour que ces métaphores soient utiles, elles doivent être utilisées avec précision.

Il y a une tendance prononcée à s’approprier des termes techniques et ensuite les utiliser de façon inexacte (‘ le système d’exploitation ‘ est la locution du jour), vraisemblablement pour apparaître mieux informé sur la technique, mais, à quelqu’un qui connaît ce que ces choses signifient vraiment, l’effet est de faire apparaître l’utilisateur de cette métaphore comme un baratineur.

Abusé de cette façon, des termes utiles deviennent progressivement dépouillés de leur sens et des remplaçants doivent être trouvés. Je m’inquiète que ceci puisse arriver avec ‘ la dette technique ‘. J’espère que ce billet aidera à clarifier sa signification.

Selon Wikipedia, Dette Technique est « La dette technique est une métaphore du développement logiciel inventée par Ward Cunningham. Il s’inspire du concept existant de dette dans le contexte du financement des entreprises et l’applique au domaine du développement logiciel ». Comme avec la dette financière, ceci est souvent inévitable et les résultats peuvent finalement être paralysants si non correctement identifiés et a traités.

Tous les projets encourent de la dette technique et ce n’est pas une mauvaise chose. Un projet sans dette avance trop précautionneusement et génère certainement des pertes. Dans un projet Lean, tout particulièrement, ce serait une erreur de produire le code sans dette tout le temps. Une approche plus raisonnable serait de tester une hypothèse en l’exécutant aussi rapidement que possible et apprenant de son utilisation dans la vraie vie. C’est seulement si les utilisateurs aiment la nouvelle fonctionnalité que cela a du sens de rembourser la dette.

Paul et moi-même en discutions l’autre jour et j’ai inventé ce que je décris comme quatre ‘catégories’ de dette.

Catégorie Une : dette accumulée au fil du temps en raison de changements de structure

Si vous développez du logiciel de façon raisonnable, vous construirez sur le travail d’autres en utilisant des structures prédéfinies – comme « Ruby on Rails » – qui sont largement comprises et supportées. Une des caractéristiques de telles structures est qu’elles évoluent, parce que la seule alternative serait l’atrophie.

Dans une structure saine, ces changements rendent les choses plus simples, plus sécurisées, plus rapides, plus faciles à maintenir, plus flexibles et plus riches en fonctionnalités. Le compromis est qu’elles n’assurent souvent pas la compatibilité-arrière. Aussi, à moins que votre équipe de développement ne fasse l’effort d’adopter les nouvelles caractéristiques, vous encourrez progressivement de la dette technique. Pourquoi ?

Il est presque inévitable qu’une structure s’améliore au point que vous vouliez adopter les versions plus récentes, même s’il s’agit simplement d’appliquer un patch de sécurité. Si vous ne gardez pas un œil attentif sur ces changements dans les fondations et ne maintenez pas votre code de base relativement à jour, il deviendra de plus en plus difficile d’adopter les versions plus récentes. Peut-être quelqu’un sortira-t-il un nouveau plug-in, ou intégrera un nouveau service social auquel vous tenez. Mais qui va prendre le temps d’écrire le code pour le supporter sur les versions antérieures ?

Cette sorte de dette est la moins destructrice et peut facilement être évitée en adoptant une bonne stratégie de mise à jour. Il ne suffit pourtant pas de simplement mettre à jour la plate-forme sous-jacente. Vous devez aussi prendre le temps de vous assurer que votre système adopte les nouveaux principes de la structure qui a changé pour qu’il puisse tirer le plein avantage des nouvelles fonctionnalités.

Catégorie Deux : les développeurs cherchant à se senti plus à l’aise

Une des compétences que vous devez acquérir pour être un excellent développeur de logiciels est la capacité de travailler avec du code écrit par quelqu’un d’autre. Quelqu’un peut venir et récrire un système à partir de zéro, mais seulement d’excellents développeurs peuvent vraiment faire un bon travail de maintenance du code de quelqu’un d’autre.

Beaucoup de développeurs n’aiment pas le faire et vous les entendrez souvent dire « Le code de base a trop de dette technique et doit être récrit ». C’est un peu comme dire que les fenêtres dans votre maison sont sales et donc le bâtiment doit être démoli et reconstruit.

Selon mon expérience, au moins 99 % du temps, quand on vous dit que quelque chose doit être récrit à partir de zéro, on vous dit juste que le développeur est trop paresseux pour se donner la peine de comprendre le code de quelqu’un d’autre.

Vous feriez mieux d’ignorer un tel conseil et vous trouver simplement de meilleurs développeurs. Concentrez-vous plutôt sur les trois autres catégories de dette.

La catégorie deux de dette est presque toujours de la dette fantôme.

Catégorie Trois : l’héritage du pragmatisme

La réalité du développement logiciel de manière professionnelle consiste en ce qu’il n’y a jamais assez de temps pour faire un travail parfait. Tôt ou tard, vous devrez vous boucher le nez et implémenter quelque chose d’une façon bien moins qu’idéale afin de terminer dans les délais et le budget.

Comme toute dette raisonnable dans le monde réel, ceci n’est pas toxique. Souvent vous pouvez vous permettre d’accepter un compromis sur la qualité, mais savoir quand est une caractéristique que seuls possèdent les bons développeurs.

Voici la chose clé de la saine dette de catégorie Trois: le coût d’implémenter une fonctionnalité d’une façon sous-optimale est le coût de faire de ceci Deux fois ! Une fois pour terminer dans les délais et une fois à la ré-implémenter de façon plus durable.

Si vous échouez à rembourser la dette dans une période raisonnable, alors vous a fait l’équivalent de mettre votre carte de crédit dans le rouge. Et, tôt ou tard, vous finirez avec de la Catégorie dette numéro Quatre.

Catégorie Quatre : Impossible d’avancer

La Catégorie Quatre est le prêt hypothécaire à haut risque de la dette technique.

Accumulez assez de dettes de Catégories Un ou Trois et vous constaterez qu’il devient presque impossible d’ajouter de nouvelles fonctionnalités à un système existant d’une façon opportune. Vous constaterez probablement aussi que vous avez beaucoup plus de bogues dans votre système qu’il est acceptable et vous dépenserez aussi davantage sur la maintenance opérationnel. Avant cette étape, vos utilisateurs auront probablement commencé à remarquer des erreurs, des failles de sécurité ou des problèmes de performance.

Ces choses sont le coût d’entretien de la dette qui ressemble aux intérêts sur vos achats à crédit et que vous devez encore trouver une façon de rembourser.

Évidemment, ceci est une situation que vous devriez vous efforcer d’éviter, mais elle est trop courante. C’est que les gens oublient de compter le coût de remboursement de la dette qu’ils ont accumulée au fil du temps. On se sent bien quand on ajoute des fonctionnalités, comme on se sent bien quand on va faire du shopping, mais, tout comme avec vos finances domestiques, la discipline est sa propre récompense à long terme. Vous pourrez vous permettre de dépenser plus de votre argent sur de nouvelles fonctionnalités au fil du temps si vous réglez vos dettes de façon raisonnable. Seulement, vous ne pourrez pas le faire immédiatement.

Si vous vous trouvez dans cette situation, il peut être tentant parfois de vous demander si cela vaut la peine de recommencer à partir de zéro, mais c’est une réaction extrême au problème, l’équivalent se déclarer en faillite personnelle. Mieux vaut de créer un plan structuré pour rembourser la dette sur une période de temps raisonnable.

Si méticuleusement géré, le résultat peut être une amélioration générale du système, qui devient moins cher à supporter et améliorer et des utilisateurs plus heureux.

Pour mieux comprendre la dette technique tant côté business que technique, je vous propose de suivre ce webinar en anglais. Steve McConnell y explique en détail les types différents de dette technique, quand les organisations devraient et ne devraient pas les contracter et les bonnes pratiques de management, suivi et remboursement de la dette. Vous gagnerez en perspicacité dans la façon d’utiliser la dette technique stratégiquement et aussi comment garder le personnel technique et business impliqué dans le processus.