Comment rembourser votre dette… technique

Identifiez les actifs toxiques dans vos développements logiciels

Comment rembourser votre dette… technique

Identifiez les actifs toxiques dans vos développements logiciels

Un développement logiciel est un processus où diverses décisions de conception ou de programmation peuvent résulter en une dégradation de la qualité du code.
Celles-ci devraient idéalement être corrigées dès que possible.
En l’absence de correction, ce passif aussi appelé "dette technique" se comporte comme une dette financière et les actions correctives deviennent plus coûteuse avec le temps.
Il est donc conseillé de corriger au plus tôt de manière à rembourser moins d’intérêts !
Cet article donne une introduction au concept de dette technique et la manière de la gérer.

En quoi consiste la dette technique

La dette technique est un concept du début des années 90 mais qui revient à l’avant de la scène depuis 2 ou 3 ans.
Le concept est le suivant.
Lorsque vous développez ou faites développer un logiciel, certaines décisions qui affectent négativement la qualité du code source sont prises : choix d’une librairie non standard, manque ou absence de tests pour pouvoir respecter les délais imposés,…
L’ensemble des corrections nécessaires pour satisfaire les préconisations en matière de bonne programmation est appelé dette technique.

Vous pouvez choisir d’apporter les corrections maintenant, auquel cas vous remboursez votre dette technique. Vous pouvez aussi choisir de ne rien faire mais, comme pour une dette financière, les intérêts augmentent avec le temps et vous devrez rembourser davantage. Bien entendu qui parle de dette, parle d’argent. Le concept de dette technique est un moyen simple de fixer un coût à la non-qualité des développements logiciels.

Quelle est la dette technique de mon application ?

Tout commence par une cartographie des mauvaises pratiques de programmation dans le code source de l’application. Cette cartographie identifie les mauvaises pratiques, leur occurrence et leur attribue une sévérité. Un effort de correction est estimé pour chaque catégorie d’erreur. La somme des efforts de correction des mauvaises pratiques les plus sérieuses (c’est-à-dire ayant un impact important sur le business) donne une estimation de la dette technique.

A titre d’exemple, la société CAST a estimé, sur base de sa définition de dette technique, qu’une application d’environ 374.000 lignes de code avait une dette technique supérieure à 1 million d’euros.

Supposons que j’aie une dette technique : que faire ?

Sur base de cette cartographie, il est possible d’identifier les causes profondes des mauvaises pratiques (manque de formation, mauvaise habitude héritée de développements antérieurs, etc.) et de planifier des remèdes :

  • A court terme : par exemple, remplacement d’une instruction par une instruction plus performante.
  • A moyen terme : par exemple, utilisation de librairies standards pour la gestion des fichiers plutôt que des composants faits maison.
  • Et à long terme : par exemple, formation sur les modèles de conception/design patterns.

Bien sûr, dans certains cas, notamment lors de la reprise de code (legacy), il n’est ni envisageable, ni opportun de rembourser la dette technique jusqu’au dernier centime. On tomberait alors dans la sur-qualité (qui elle aussi a un coût). Il est donc important d’identifier les gains en qualité de chacune des catégories d’erreurs de façon à optimiser le retour sur investissement des corrections.

Comme annoncé plus haut, il est aussi possible de ne rien faire et d’attendre l’arrivée d’un expert. Le seul fait d’être au courant de l’ampleur de sa dette technique, ou de contrôler l’évolution de celle-ci est déjà un point très positif. Il est aussi possible d’évaluer l’efficacité du processus de développement en comparant la dette technique avec l’effort consommé pour la production (spécifications, analyse, conception, développement, tests) du logiciel. Un benchmark de cette efficacité sur l’ensemble des développements permet d’isoler les « actifs toxiques » dans votre portefeuille d’applications !

En résumé

La dette technique est un outil simple à mettre dans la trousse de tout bon décideur.
Pour ce faire voici les étapes nécessaires :

  • Etre conscient que tout développement produit une dette technique suite aux décisions prises qui affectent la qualité du code source produit.
  • A répéter à fréquence régulière :
    • Estimer la dette technique engendrée par les mauvaises pratiques de programmation via une cartographie des mauvaises pratiques de programmation.
    • Sélectionner un ensemble approprié des mauvaises pratiques à corriger sur base du contexte du développement (phase du développement, type de développement, ressources disponibles, etc.).
    • Mettre en place les corrections adaptées.
    • Estimer la dette technique résultante de manière à évaluer l’efficacité des corrections.

Contactez le CETIC

Le CETIC vous aide à estimer votre dette technique et vous aide dans la résolution de cette dette technique via des audits de qualité de code et des audits de qualité des processus de développement.
Contactez-nous pour en savoir plus !