1️⃣ On connaît la "dette technique", souvent présentée à tort comme "le code dégueulasse" alors qu'elle désigne à l'origine "l'écart qui se creuse entre l'implémentation et la compréhension du problème qui a entre-temps évolué" [1].
La première est simple à éviter: évitez d'engager des marioles pour pas cher.
La seconde beaucoup moins... quoique: idem donc.
2️⃣ Voilà donc la "dette cognitive" qui désigne "l'incapacité de comprendre le code plus tard, et le problème qu'il cherchait à résoudre".
Cette dette n'est pas nouvelle en vrai, même si l'IA va l'amplifier. Mon mantra "le problème de la tech c'est l'infidélité [des développeurs]" désigne exactement le même risque, sans aucune IA en cause.
Bref, évitez d'engager des marioles gonflés à l'IA (qui disparaîtront dans 3 mois).
3️⃣ On pourrait aussi inventer la "dette systémique", qui désignerait "ce choix architectural ultra complexe qui va prendre 10 ans à réduire". Par exemple les microservices et autres systèmes distribués introduits beaucoup trop tôt.
Évitez d'engager des marioles gonflés au buzz architectural.
4️⃣ Ou encore la "dette d'(in)utilité" qui désigne "la fonctionnalité ajoutée un peu trop vite, mais que 1% d'utilisateurs empêche de supprimer".
Là c'est votre responsabilité, tout n'est pas la faute des devs non plus.
5️⃣ La "dette de frontière" explique pourquoi tout d'un coup on jette des milliers de tests unitaires alors que le domaine n'a pas changé: ils couvraient la solution plutôt que le problème à résoudre.
Ca vous dépasse complètement donc : évitez d'engager des marioles.
6️⃣ Et celle dont on ne parle jamais, la "dette financière" qui désigne le simple fait que les revenus du logiciel n'ont jamais rattrapé les coûts engagés. Parce qu'on a pas appris à calculer face à l'incertitude.
Moi aussi. Moi non plus.
#SoftwareEngineering #IA
il faudrait raffiner nos termes. Dette conceptuelle pour la seconde ? Dette "vas-y, fais vite" pour la première ? ↩︎