Le deuxième moyen le plus rapide d’ennuyer un développeur est de parler de la dette technologique, qui est un terme de développement de logiciels désignant ce qui se passe lorsque vous prenez quelques détours pour lancer une fonction ou une fonctionnalité plus rapidement.
Le moyen le plus rapide de provoquer l’ennui le plus total est d’utiliser une métaphore financière pour expliquer pourquoi la dette technologique se produit et quand y faire face de manière stratégique.
Cependant, comme l’a dit un jour le grand « philosophe du logiciel » Andy Warhol, « Vous devez laisser les petites choses qui vous ennuient habituellement vous enthousiasmer soudainement ». C’est dans cet esprit que nous nous aventurons dans les eaux sombres afin de mieux vous expliquer la dette technologique.
La dette technologique est plus une question de priorité que de procrastination. Les équipes de développement de logiciels choisissent délibérément de ne pas écrire un code techniquement parfait ou de ne pas tester quelque chose de toutes les façons afin de pouvoir lancer une version. En d’autres termes, l’équipe n’est pas paresseuse ; elle jongle simplement avec les compromis.
Comme promis, voici la métaphore qui provoque l’insomnie. (Vite, prenez le café !) La dette technologique est comme un emprunt à la banque. Disons qu’une entreprise souhaite développer son activité plus rapidement, elle emprunte donc de l’argent pour acheter de la publicité en pensant qu’elle aura un meilleur rendement plutôt que de se développer plus lentement grâce au bouche à oreille.
Cependant, la triste réalité des prêts est qu’ils doivent être remboursés à un moment donné. Plus le prêt est en cours – et plus les intérêts composés s’accumulent – plus il devient handicapant (surtout si le rendement ne se matérialise jamais).
Il en va de même pour les dettes technologiques. Il existe de nombreuses bonnes raisons de contracter un « prêt » pendant le développement d’un logiciel, par exemple pour mettre une nouvelle fonctionnalité sur le marché avant les concurrents ou pour tester une fonctionnalité auprès de prospects et de clients. Cependant, cela se fait généralement au détriment d’autre chose, comme un code stable.
Voici le véritable tueur silencieux : Contrairement à une entreprise qui obtient un prêt d’une banque (dans lequel le principal et le taux d’intérêt sont clairs comme de l’eau de roche), l’équipe de développement de logiciels ne connaît ou ne comprend pas entièrement le coût réel du « prêt » de la dette technologique la plupart du temps. L’équipe peut penser qu’elle contracte un micro-prêt alors qu’en réalité, elle signe un prêt à taux élevé.
Cela se produit généralement parce que l’équipe de développement n’a pas défini le niveau de qualité qu’elle est prête à accepter pour chaque nouvelle version. Cette norme est connue dans le monde des développeurs sous le nom de « The Definition of Done ».
Voici ce que cela signifie. Chaque équipe de développement de logiciels doit décider quand la fonction ou la fonctionnalité qu’elle crée est prête à être lancée, autrement dit, quand elle est considérée comme « terminée ». Invariablement, une fonctionnalité donnée n’est jamais vraiment parfaite, car le temps et l’argent ne sont pas des ressources illimitées. L’équipe doit donc décider quand cette fonctionnalité est « suffisamment bonne » et combien de dettes techniques elle est prête à accumuler et à réparer plus tard.
Si l’équipe de développement n’a pas convenu collectivement d’une définition ferme de la notion de « bon » (par exemple, faut-il procéder à un test de charge, à une révision du code ou à des tests automatisés ? En d’autres termes, votre taux d’intérêt sur le « prêt » pourrait monter en flèche et vous n’avez qu’une vague idée de l’ampleur de cette hausse.
Pour être clair, il n’y a pas de bonne ou de mauvaise façon de définir la « définition de l’achèvement » d’une équipe. Les besoins et les circonstances de chaque entreprise étant différents, le montant de la dette technologique qu’une équipe de développement est prête à assumer dépend entièrement de la situation.
Ce qu’il faut retenir de tout cela, c’est que la dette technologique n’est pas mauvaise en soi, mais qu’il faut simplement être très intentionnel. Réunissez votre équipe de développement et travaillez en groupe pour définir tous les paramètres clés de votre Définition ainsi que le plan d’action pour » rembourser » la dette technologique qui pourrait s’accumuler à cause d’elle.
Avec cette stratégie en main, vous ne devriez pas avoir à craindre que votre dette technologique devienne ingérable – mais hélas, vous devrez toujours vous soucier de la façon de faire passer le message à vos amis.
Lire l’article complet sur Forbes.com
