Maîtriser sa dette technique

Le code de vos projets n’est jamais parfait et se détériore avec le temps. C’est un problème important car, s’il est mal maîtrisé, vos temps de développement seront plus longs et vos bugs plus fréquents.

(Lire la suite…)

La dette de nos systèmes d’information

L’endettement de nos systèmes d’information

Ward Cunningham introduisait en 1992 la métaphore de la dette technique faisant une analogie entre les coûts futurs liés aux choix de conception logicielle et une dette financière. Celle-ci introduisait la nécessité de mettre en application des Design Patterns permettant de mieux maitriser la dette technique.

En 2009, Ward Cunningham revenait lors d’une interview sur le fait que l’objectif premier n’était pas d’apurer totalement la dette technique mais de s’attacher à la maitriser dans le temps.

Pour illustration, l’éditeur CAST Software a publié un rapport qui évalue le montant moyen de la dette technique à 2,82$ par ligne de code. Le sujet de la dette technique n’est pas tant le montant que son échéance – date à laquelle il devient nécessaire d’apurer la dette technique – et ses intérêts – surcoûts liés à une conception technique peu flexible.

Dette technique versus dette du SI

La dette technique désigne l’inadéquation technique d’un logiciel, qui peut être exigée par des demandes d’évolution futures. La nécessité de financer des évolutions de nos systèmes d’information peut provenir de bien d’autres sources :

  • Evolutions fonctionnelles demandées par les utilisateurs
  • IT refresh demandés par les éditeurs et les évolutions technologiques
  • Evolutions organisationnelles (fusion, acquisition, externalisation, …)
  • Evolution des paradigmes business (rollover market, multi-canal, servicing, …)
  • Evolutions réglementaires (comptable, autorité de supervision, …)

La dette technique n’est finalement qu’une partie de la dette du système d’information.

Dans un autre article, je tentais d’approximer le montant minimum de la dette du SI à 55% du montant initial du projet sur 3 ans.

Rationalisation du SI

La rationalisation du SI a été successivement associée à une réduction des coûts, puis à de la ré-urbanisation du SI et de plus en plus à du downsizing du SI. A ce titre, le principal levier de la maitrise de la dette du SI est la réduction de la taille du SI.

Les outils de la rationalisation du SI sont multiples :

  • Faire plus avec moins de lignes de code. Le rapport entre les technologies diffère fortement entre COBOL, C, Java, Ruby et .NET
  • Zone rationalisée/Zone Sandbox métier. Dans une UPSI, nous évoquions l’intérêt d’une zone du SI non rationalisée permettant le prototypage permanent
  • Minimiser les tailles des « socles » techniques plus difficiles à faire évoluer
  • Maximiser les investissements SI « rentables », c’est-à-dire à forte valeur d’usage

Conclusion

Pour maitriser la dette de nos systèmes d’information, il est nécessaire de rompre avec nos réflexes qui nous incitent à glorifier la complexité et l’optimisation des coûts passés. Mon intime conviction est que la maitrise de nos systèmes d’information passe par le développement d’une compétence « d’asset manager de l’information » permettant de reconnecter la valeur d’usage aux investissements.

Mesurer la qualité d’un projet pour le désendetter

En ingénierie logicielle, tant qu’un projet se développe, la dette technique s’accumule inexorablement. Les sessions de refactoring sont là pour contrebalancer cette tendance et leur mise en place régulière garantit la maintenabilité du projet. Mais ce qui est délicat avec la dette technique, c’est qu’elle n’est pas vraiment mesurable, et comme l’iceberg, on n’en voit que la partie émergée. Résultat, le refactoring est souvent sous-estimé et mal maitrisé. Si on ajoute à cela une mauvaise couverture de test, refondre le code applicatif fait peur, fait mal. Plus personne n’a l’audace de le tenter, et à long terme, c’est la banqueroute assurée du projet.

L’objectif de cet article est de proposer une approche efficace pour savoir comment attaquer efficacement un grosse refonte d’un code mal couvert par les tests. Cette tâche technique est divisée en plusieurs problématiques : comment déterminer les zones de risque du projet, trouver où poser les tests pour sécuriser l’étape de refactoring et trouver les zones à refactorer.

Pour rendre l’article concret, nous allons utiliser à titre d’exemple XDepend qui est un outil d’analyse de code statique java. En effet, on parle d’amélioration de la qualité, donc pour juger de l’efficacité de nos actions, il faut pouvoir les mesurer. (Lire la suite…)