Dette technique : comment cela affecte votre business ?

1. Qu'est-ce que la dette technique ?
2. Types de dette technique les plus courants
3. Causes les plus courantes de dette technique
4. Délai - Coût - Qualité
5. Comment la dette technique affecte-t-elle votre entreprise ?
6. Principale chose à retenir de cet article

Qu'est-ce que la dette technique ?

Wikipédia le décrit ainsi :

dans le développement de logiciels, la dette technique (également connue sous le nom de dette de conception ou dette de code) est le coût implicite des retouches supplémentaires causées par le choix d'une solution simple (limitée) maintenant au lieu d'utiliser une meilleure approche qui prendrait plus de temps.

Bien que la description soit généralement assez correcte, ce n'est pas si simple. La dette technique est un coût caché de chaque projet informatique, mais tous les cas ne sont pas dangereux ou causés par de mauvaises décisions de votre équipe de développement (comme vous le verrez dans l'explication ci-dessous).

Le mot «dette» n'est pas une coïncidence, car il a de nombreux attributs en commun avec la dette économique. Il est absolument important de le « rembourser » régulièrement. Ignorer et accumuler la dette technique peut entraîner des conséquences fatales, voire la faillite dans le pire des cas. Dans le monde du développement de logiciels, cela signifie qu'un tel logiciel ne fonctionne pas ou ne peut pas être développé davantage, ce qui entraîne des pertes d'investissement importantes.

Fait amusant : dans l'étude américaine "The cost of Poor quality software in the US" de 2018, Herb Krasner calcule que le coût global des logiciels mal conçus est d'environ 2,8 milliards de dollars. En comparaison, c'est plus que les valeurs du PIB de la plupart des pays du monde.

Types de dette technique les plus courants

Voyons donc quels types de dette technique vous pouvez généralement rencontrer. Il existe essentiellement 4 types de dette technique.

Prudent et intentionnel

Il s'agit d'un pari calculé. L'équipe sait que la dette technique s'accumule, mais elle décide de continuer à livrer le projet. Cette solution est acceptable, si le risque est faible ou si le rendement possible du lancement antérieur est suffisamment élevé pour couvrir les frais de « remboursement » de la dette technologique initiale.

Insouciant et intentionnel

C'est le pire. L'équipe de développement choisit intentionnellement le chemin le plus court pour atteindre l'objectif final, sans se soucier des implications de la dette technique, des problèmes qui surviennent et des coûts plus élevés plus tard sur la route.

Prudent et involontaire

L'équipe est bien informée, capable, utilise les meilleures pratiques et choisit la meilleure solution connue à ce moment-là. Le problème est que l'informatique en tant qu'industrie évolue constamment et chaque année, il existe de nouvelles façons d'aborder et de résoudre différents problèmes. C'est aussi la raison pour laquelle nous mentionnons que la dette technique fait partie de tout projet informatique. Au fil des années, il existe de meilleures façons de résoudre les mêmes problèmes, donc pour améliorer votre projet, vous refactorisez.

Imprudent et involontaire

L'équipe ignore les pratiques de conception ou le code propre, généralement en raison du manque d'expérience, sans même se rendre compte de l'ampleur des problèmes dans lesquels elle s'engage.

Causes les plus courantes de dette technique

Nous connaissons maintenant les types de dette technique les plus courants, mais quelles sont les causes les plus courantes en plus de celles mentionnées ci-dessus ?

• la pression du temps,
• tests insuffisants,
• technologies obsolètes,
• l'absence de tout document,
• code désordonné,
• mauvaise architecture,
• manque de compétences de l'équipe de développement.

Délai - Coût - Qualité

Le monde des affaires a quelques "règles d'or" et en voici une. De la trinité bien connue Temps - Coût - Qualité, vous ne pouvez en avoir que deux. Si vous poussez votre équipe de développement à créer quelque chose de bon marché et de rapide, vous n'obtiendrez pas la qualité. Si vous voulez de la qualité et une livraison rapide, ce ne sera pas bon marché. Cela vaut dans le développement de logiciels personnalisés autant que partout ailleurs, sinon plus. Le mauvais choix de deux de ces trois options peut souvent entraîner la dette technique.

Nous ne sommes pas des nerds et nous comprenons que parfois la dette technique est inévitable et est même quelque chose qui a du sens dans un cas particulier (ex : développement rapide de MVP pour la validation du marché). Dans ce cas, lorsque vous avez des ressources limitées et que vous souhaitez tester l'ensemble du projet dès que possible, il n'est peut-être pas logique de construire une architecture complexe prête à évoluer pour des millions d'utilisateurs, de préparer de grands tests automatisés, différents bacs à sable, des CI/ pipeline de CD et d'autres aspects importants du développement moderne. Vous vous concentrez simplement sur le fait de le faire le plus rapidement possible. Et ce n'est pas grave tant que vous comprenez les risques et les coûts impliqués à l'avenir (même une réécriture complète de la première version de l'application pourrait être nécessaire dans certains cas).

Le fait est que la dette technique calculée ne représente malheureusement généralement qu'un petit pourcentage des projets.

Ce que nous rencontrons habituellement chez GIFTED lorsque, par exemple , le sauvetage de projets , est exactement le contraire ou plus précisément, une dette technique imprudente et intentionnelle de la description ci-dessus. La dette technique est négligée, en augmentation constante, non documentée et non gérée.

Il y a aussi une chose qui doit être dite. L'industrie informatique évolue comme aucune autre dans le monde. Les technologies qui sont à la pointe de la technologie cette année pourraient avoir des versions majeures ou des technologies alternatives nettement meilleures l'année prochaine. C'est comme ça que ça se passe. Vous devriez toujours essayer de garder votre projet à jour. Nous ne disons pas que vous devez mettre à jour le premier jour où une nouvelle version de la technologie est publiée (au contraire, nous vous déconseillons fortement de le faire à cause des bugs qui apparaissent généralement dans les premiers jours), mais il est conseillé de conservez votre projet sur la dernière version stable et prise en charge à long terme dans un délai raisonnable. D'une certaine manière, cela peut aussi être appelé la dette technologique en soi, c'est pourquoi au début de l'article, nous parlons du fait que la dette technologique fait partie de chaque projet.

Comment la dette technique affecte-t-elle votre entreprise ?

En termes simples, beaucoup. Voici quelques exemples :

• vitesse de développement et coût des nouvelles fonctionnalités,
• coût de maintenance,
• la satisfaction de l'équipe de développement,
• satisfaction du client,
• vos processus métiers,
• la communication,
• last but not least votre réputation.

Tout dépend de la nature de votre entreprise. Tout cela peut également être directement ou indirectement converti en pertes monétaires.

Principale chose à retenir de cet article

Considérez la dette technique comme une partie vivante de votre projet. Réservez du temps à vos développeurs pour y remédier. Surveillez-le et documentez-le (une simple tâche JIRA mise à jour ou une page Confluence peut faire des merveilles). Travaillez avec votre dette technique et en récupérez continuellement des morceaux. C'est la seule façon de le garder sous contrôle à long terme. Si vous ne le faites pas, des coûts plusieurs fois plus élevés vous rattraperont probablement tôt ou tard.