Technical Debt : No penalty for early payment

http://blog.castsoftware.com/technical-debt-no-penalty-for-early-payment/

Posté Par Jon sur le blog de Cast Software

Nous sommes une société de débiteurs. Nous nous endettons pour nos voitures, nos maisons, et grâce aux cartes de crédit nous nous endettons même pour l’épicerie et l’essence.

Dans le développement logiciel, comme dans la vie, avoir un peu de dette peut en réalité être une bonne chose pour faire progresser des choses plus critiques. Bien que dans des blogs précédents nous ayons défini la dette technique comme « le coût pour réparer des problèmes de qualité structurels d’une application qui, si laissés défectueux, pourraient mettre le business en danger », engager une petite et raisonnable somme de dette technique peut en réalité faire avancer le projet plus rapidement et faciliter l’atteinte de l’objectif d’avoir un logiciel exécutable. C’était la pensée de Ward Cunningham, le créateur du concept de dette technique.

Mais comme Derek Huether l’indique dans son blog de conseils technologiques pour le Dumas Lab à propos de la Dette technique : « Comme toute dette habituelle, vous vous trouverez tôt ou tard devant le besoin de la rembourser. »

Huether note aussi que tout comme une dette dans nos vies personnelles, si non remboursée, d’une façon ou d’une autre :

…elle reviendra pour vous hanter. Si votre bidouille d’une solution ne revient pas mordre l’équipe de développement, elle hantera probablement le bureau de support technique, l’équipe de support, ou quelqu’un d’autre en aval.

Il ajoute alors :

Comme toue dette, vous vous retrouvez devant le besoin de la rembourser tôt ou tard …, j’ai vu (et vois) ce que la dette technique peut faire à la vélocité d’une équipe. Elle les prive d’un temps précieux, après coup. L’équipe de développement achète l’idée que faire des choses de la mauvaise manière, qui peut sauver un peu de temps dans l’immédiat, vaut les risques et le coût total. C’est vraiment une vue à court terme du processus de réflexion. La dette technique ressemble à l’obtention d’un prêt d’un usurier qui lance les dés pour décider de votre taux d’intérêt. Aussi, si vous n’êtes pas obligés de prendre le risque, ne le prenez pas.

Mais la dette technique est-elle vraiment une proposition de type tout ou rien ?

Combien est assez ?

Quand elle en vient à la Dette Technique, une société doit déterminer combien, si quoi que ce soit, devrait être investit pour y  remédier. La meilleure façon de le faire est en donnant une valeur monétaire (en monétisant) la dette technique pour donner une valeur financière à la qualité structurelle de l’application. Cela permet de comparer les coûts informatiques aux pertes potentielles coté business en raison d’un échec qui n’était pas possible précédemment (avant de contracter cette dette).

Le but de monétiser la dette technique est de maintenir le nombre de violations de la qualité structurelle – ou ce qui est plus important, le coût de les réparer – bien en dessous du coût que la société encourrait si le logiciel devait être déployé et aboutir à un échec.

Un Plan d’Action pour la Dette Technique

Pour déterminer le point de basculement des problèmes de qualité structurelle et du coût pour les réparer, une société devrait utiliser une plate-forme d’analyse et de mesure automatisée pour évaluer la qualité structurelle de leurs cinq applications les plus cruciales à la mission de l’entreprise. La façon dont chacune de ces applications est construite, leur qualité structurelle devrait être mesurée à chaque version majeure et une fois qu’elles fonctionnent, la qualité structurelle de l’application devrait être mesurée chaque trimestre.

La clé est de garder un œil vigilant sur le compteur des violations; contrôlez les changements et calculez la Dette Technique de l’application après chaque évaluation de qualité. Quand une valorisation monétaire de la dette technique a été vérifiée, elle peut être comparée à la valeur business pour déterminer combien de Dette Technique est trop et combien reste acceptable par rapport au retour marginal sur la valeur business. Pour établir une structure pour calculer la perte de valeur business en raison des violations de qualité structurelles, nous recommandons “The Business Value of Application Internal Quality” par Dr. Bill Curtis.

Une fois que ce point de basculement est déterminé, une société peut décider où et quand elle doit aborder les problèmes de qualité structurelle qui ont créé la dette technique.

La partie agréable de se débarrasser de dette technique est la même que pour la dette personnelle: cela évite le paiement de plein d’intérêts. Pourtant, il n’y a aucune pénalité à rembourser en avance… en fait, cela apporte une récompense significative grâce à un logiciel de meilleure qualité.