Loading...Aujourd’hui dernier article de cette série pour expliquer le calcul de la dette technique et les coûts associés à la non-gestion de la dette fonctionnelle (functional debt).
Comment convaincre de supprimer une fonctionnalité peu utilisée
Laissez-moi vous raconter le cas assez frustrant de code excédentaire que personne n’a osé supprimer. Ce cas est d’ailleurs non résolu, par manque de conscience collective et de courage. Finalement, c’est un exemple de WASTE pour reprendre une terminologie LEAN.
Il ne faut pas avoir du sang de navet dans les veines pour réduire la dette logicielle ? Vous n’osez pas supprimer une fonction ? Faites le calcul de la dette technique et fonctionnelle. Estimez le ROI d’une fonction inutile avec votre CTO ou avec un CTO de la plateforme Pentalog. Cela vous motivera peut-être à alléger votre code… et votre budget de développement informatique.
Il s’agissait d’une fonctionnalité qui avait pris presque 6 mois à développer, avec 5 personnes. Elle n’avait pas eu le succès escompté et avait finalement été abandonnée d’un point de vue commercial.
Mais cette fonction était restée dans le produit. Aïe (×_×#)
Et surtout, il restait un unique utilisateur, qui l’utilisait pour faire autre chose.
En l’occurrence, il aurait suffi de montrer au client comment utiliser un produit comme SurveyMonkey et le tour était joué…
Surtout, je pense qu’il aurait fallu expliquer le temps masqué que nous passions :
- à ne pas rénover le logiciel,
- à faire malgré tout des tests de non-régression sur cette partie
- à assurer, de temps en temps, un support très personnalisé au client qui se plaignait (en plus) que parfois cela ne fonctionnait plus.
Calcul de la dette technique et ROI d’une fonction inutile
Faisons un petit calcul de ROI, certes un peu simpliste, pour cet exemple extrême ?
Investissement initial
- 6 * 20 jours * 5 personnes * 500 € par jour = 300 000 €
pour une fonctionnalité utilisée par une seule personne au bout d’un an de mise en prod.
Coût de la non-suppression
Dans ce cas nous avions un testeur qui faisait de la non-reg. Il se trouvait que nous payions une licence d’un EAI un peu cher sur ce sujet. Et nous devions en plus, de temps en temps, faire des montées de version du socle technique…
- 1 testeur * 5 releases par an * 1 jour * 500 € par jour = 2 500 €
- 1 machine dédiée hébergée = 2 000 € par an
- Maintenance d’1 licence d’EAI = 10 000 €
NB. il s’agit d’une licence très chère (dont je tairai le nom de l’éditeur) à 20% de 10 000 € par cœur de processeur. Prenons 5 cœurs pour arrondir. - Un peu de support / màj par an : 1 développeur * 500 € * 5 releases * 2 jours = 5 000 €
- TOTAL = 19 500 €
Calcul de la dette technique
Donc pendant presque 7 ans (et « still counting » à ma connaissance), la conséquence directe de ne pas avoir expliqué à quelqu’un comment utiliser SurveyMonkey (quitte à lui payer la formation d’ailleurs) a coûté :
- 19 500 € par an + 300 000 € d’investissement initial
- soit au total 136 500 € + 300 000 €.
Bien évidemment la société de l’utilisateur en question ne payait pas ce prix de 19 500 € par an…
Quant au coût indirect de la dette technique, c’est
- de la vélocité en moins à chaque release / sprint,
- un sentiment de non-maîtrise du code et
- l’auto-limitation des équipes pour faire des changements et donc potentiellement innover !!!
Du bon usage de YAGNI
(You ain’t gonna need it)
YAGNI, tout le monde connaît ce principe d’extreme programming ou dit le connaître. Mais son application rigoureuse peut vous permettre de limiter la dette fonctionnelle. Cela ne vous empêchera pas à 100% de ne pas en avoir. Mais au moins vous saurez pourquoi votre logiciel « s’encrasse » et qu’il faut régulièrement prendre le temps de dégraisser le mammouth.
Le schéma ci-dessous synthétise le concept YAGNI et surtout les coûts induits par la dette fonctionnelle et technique.
- « Cost of carry » c’est la maintenance même passive
- « Cost of delay » c’est ce que vous auriez pu générer comme revenu supplémentaire en faisant une autre fonctionnalité.
- Sur ce schéma, la dette technique n’est finalement que dans la bulle « Right feature, built wrong »…
YAGNI – Coûts directs et coûts indirects (source : https://martinfowler.com/)
Donc en proportion, sur ce schéma, si on considère qu’il y a autant de chance pour une équipe de générer de la dette technique que de la dette fonctionnelle, gérer la dette logicielle, c’est gérer les deux tiers du code créé par équipe.
Conclusion : améliorez vos actifs logiciels
En termes de volume et risque, dette fonctionnelle = dette technique !!!
∑ Dette Fonctionnelle ≅ ∑ Dette technique
Et après, vous continuerez à me dire que, franchement, cela ne sert à rien de gérer la dette fonctionnelle ? Alors que par ailleurs, tout le monde se targue d’être LEAN ou de faire du Growth Hacking ou que sais-je encore ?
Eliminer le WASTE ce n’est pas partir « from scratch » à chaque fois. C’est aussi améliorer ses actifs logiciels qu’on a trop tendance à considérer comme du « legacy »…
Je vous propose ces quelques articles, pour terminer, compléter et approfondir :
- Functional Debt : https://apiumhub.com/tech-blog-barcelona/technical-debt/
- Managing Software Debt : http://www.gettingagile.com/2008/10/20/managing-software-debt-article/
- Une explication des coûts cachés au travers du principe YAGNI : https://martinfowler.com/bliki/Yagni.html
Conformément à la politique d’utilisation de la marque déposée, SurveyMonkey n’est pas associé à Pentalog et n’endosse ni ne sponsorise ce site web.
Lisez aussi :
Réduire la dette technique et fonctionnelle « Functional Debt » – Part #3
Dette fonctionnelle vs. dette technique – Part #2 : comment identifier la “functional debt”
Gérer la dette technique, c’est bien, mais qui gère la dette fonctionnelle ? – Part #1
