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.
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.
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.
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 :
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 !
La dette technique est un outil simple à mettre dans la trousse de tout bon décideur.
Pour ce faire voici les étapes nécessaires :
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 !