Styles

samedi 28 juin 2008

L'arme absolue de la qualité : la CheckList

Le problème avec l'informatique c'est qu'elle ne supporte pas l'imprécision, l'à-peu-près. La machine sur laquelle tourne un programme n'ayant aucune intelligence en soi, et les langages employés sont finalement, tellement bas niveau qu'il faut toujours penser à tous les détails, ceux qui font toute la différence entre un code qui tourne correctement et un code boggué.

Le diable est dans les détails, c'est sûre, mais l'excellence aussi. On trouve dans tous les bonnes bibliothèques informatiques, des tonnes de livres remplis de bonnes pratiques qu'on doit mettre en oeuvre dans tous les cas possible est imaginable de l'activité de développement d'un logiciel.

Or qui peut se targuer de connaître toutes ses bonnes pratiques, et qui est capable de les utiliser à bon escient et à tous les moments opportuns ? Avoir tous les détails en tête n'est pas humain, puisque le fondement de l'esprit humain est l'oubli. Le programmeur de base est ainsi fait qu'il a une mémoire bien plus volatile que son PC. Comment faire pour qu'un développeur puisse coder proprement sans avoir à lire des milliers de pages de livres informatiques ?

Un des problèmes est que la maîtrise d'une matière demande beaucoup de temps, au minimum une dizaine d'année, quelque soit la matière. Or, en France tout du moins, les ingénieurs informatique ont tous tendance à ne plus vouloir programmer, passé les quelques années d'expérience, principalement par le fait que l'activité de programmation est déconsidérée par rapport aux autres métiers tournant autour. Résultat, les personnes en charge du développement d'application sont souvent jeunes et inexpérimentées, même si elles ont beaucoup de volonté.

La solution classique, simple, c'est bien sur d'utiliser des "checklists", des listes de vérification à chaque étape du processus de développement.

Un projet sans checklist ne peut produire que du code propre à chaque développeur. Il ne sera pas forcément mauvais, mais le code source sera construit sous la forme d'un écosystème avec plusieurs façon de coder différentes, de façon de traiter les erreurs différentes, d'organiser et de nommer les éléments du code, etc.

La checklist est un moyen simple et efficace. Elle peut être employée pour améliorer n'importe quel type d'activité même créative. On la voit malheureusement trop peu employée là où elle aura pourtant le plus d'impact sur la productivité de nos activités.

Dans des domaines où la qualité est un facteur important, les checklists sont au coeur de l'assurance qualité, comme par exemple chez Renault où la validation de la conception d'un nouveau modèle passe par la vérification de toutes les checklists maison, construites au cours de années et rassemblant toutes les bonnes pratiques durement apprises par l'expérience.

La checklist implique un processus minimal :

- un travail

- la vérification de ce travail au regard de la checklist.

La conception et l'utilisation de checklists est bien l'activité fondamentale de ce qu'on appelle couramment "l'assurance Qualité". La vérification à la main des checklists est assez longue et coûteuse, et on a tout intérêt à mettre les vérifications dans un processus automatique, notamment par l'utilisation d'outils.

Au niveau du code source, on dispose de beaucoup d'outils plus ou moins puissants, comme les analyseurs statiques. Chacun peut les utiliser pour soi-même mais cela prend tout son sens quand on effectue les vérifications au niveau du système de gestion des sources, lors d'un "commit" dans Subversion par exemple. Il est aisé d'ajouter des "hooks" aux évènements de base des systèmes de gestion de configuration comme CVS ou Subversion.

On ne peut pas tout vérifier au niveau d'un commit, cela prendrait trop de temps, et les développeurs se mettraient à attendre trop longtemps avant de commiter et y réfléchiraient à deux fois, voire, il ne commiteraient jamais ! C'est pour cela qu'il est intéressant d'effectuer des vérifications régulièrement sur un serveur d'intégration continue.

Aujourd'hui l'intégration continue à le vent en poupe, tout le monde en parle. Mais là où on a le plus intérêt à effectuer des vérifications, c'est aux phases amonts de la simple activité de codage.

Le coût d'une erreur étant dépendant de la phase dans laquelle elle est détectée, une erreur d'expression de besoin coûtera beaucoup moins chère à corriger lors de la phase d'expression de besoin que lors du codage de l'application. Ainsi, on a tout intérêt à vérifier les phases amonts pour éviter de grosses embûches en phase de construction.

On trouve beaucoup de checklists sur le Web, mais je n'ai pas réussi à trouver beaucoup de sites proposant une mise en commun de checklists, notamment par profession.

Ca serait vraiment intéressant de mettre en commun toutes les bonnes pratiques, sous forme de checklist à un seul endroit, directement utilisable sur les projets de développement logiciel. Les livres de Steve McConnell sont particulièrement riches en checklists et méritent vraiment qu'on s'y intéresse.

mardi 24 juin 2008

Génération automatique de tests unitaires par héritage d'assertions

Toujours à propos des assertions, je me demande s'il ne serait pas possible de générer des tests unitaires automatiquement, mais uniquement ceux qui vont faire tomber à FALSE une assertion quelconque de la routine (et à n'importe quelle profondeur). En effet, d'après le livre du magicien, au chapitre 1-1 on peut lire :

Chaque langage puissant a trois mécanismes pour combiner des idées simples pour former des idées plus complexes[1] :

- des "expressions primitives" qui représentent les entités les plus simples dont le langage se préoccupe,

- des "moyens de combinaison" par lesquels des éléments composés sont construit à partir d'éléments plus simples,

- des "moyens d'abstraction" par lesquels les éléments composés peuvent être nommés et manipulés comme des unités.
Si on s'en tient à cette définition, on pourrait imaginer qu'un langage définisse toutes les pré-conditions à respecter pour chaque "expression primitive", les assertions implicites comme par exemple pour la fonction / qui ne peut accepter un dénominateur égal à 0.
Ainsi, si vous programmez du code comme cela (en Scheme par exemple) :
(define (myfunc myval) (/ 10 myval))
Un outil pourrait construire, en analysant les combinaisons et les abstractions, un cas de test unitaire automatiquement pour faire planter cette myfunc() :
(define (myfuncTest) (myfunc 0))
; Le test unitaire généré automatiquement
; d'après l'analyse de myfunc()
On peut dire que myfunc() hérite des préconditions de toutes les fonctions auxquelles la routine fait appel. A noter qu'il n'y a aucune assertion, préconditions, invariants spécifiés au niveau de la routine myfunc(), l'outil doit être capable de les déduire de l'implémentation de la routine (comme c'est ici le cas dans la remontée de la précondition de la routine / )

Reste à définir correctement comment fonctionne l'héritage de préconditions, postconditions et d'invariants. J'ai trouvé un rapport d'étude intéressant visant à produire automatiquement les tests unitaires à partir de conditions (exprimées en JML), mais je n'ai pas trouvé ce mécanisme d'héritage de conditions.

Une solution à base de détection automatique d'invariant par un outil comme Daikon pourrait peut-être faire l'affaire... à creuser.

On peut même rapprocher ce problème à un problème de satisfaction de contraintes. Les paramètres de la routine sont les variables, leur domaine est restreint par leur type, et les pré-conditions, post-conditions, invariants sont les contraintes.

Via les mécanismes d'inférence de contraintes bien connus dans le domaine du traitement des contraintes, on pourrait imaginer calculer quelles sont les solutions (les domaines possibles) des variables de la routine en fonction de tous les appels d'autres fonctions qu'elle réalise. Ces solutions sont les pré-conditions d'appel de la routine.

Tout cela reste à explorer, si une bonne âme souhaite se dévouer à cette tâche...

[1] C'était déjà ce qu'avait noté John Locke dans An Essay Concerning Human Understanding (1690) : "The acts of the mind, wherein it exerts its power over simple ideas, are chiefly these three: 1. Combining several simple ideas into one compound one, and thus all complex ideas are made. 2. The second is bringing two ideas, whether simple or complex, together, and setting them by one another so as to take a view of them at once, without uniting them into one, by which it gets all its ideas of relations. 3. The third is separating them from all other ideas that accompany them in their real existence: this is called abstraction, and thus all its general ideas are made"

vendredi 20 juin 2008

Apprentissage, mémoire et langage

Bien que le fait de parler ou d'écrire est l'inverse de l'action concrète sur le monde physique, en informatique, il semblerait que ce soit l'inverse, écrire dans un langage de programmation est justement la seule et unique forme qui permette l'action, l'action d'un automate électronique, projection du moi (psychologie de comptoir bonsoir).

C'est quelque chose d'assez unique d'avoir seulement à parler pour que la chose obéisse immédiatement. Face à ce pouvoir du langage de programmation, le programmeur doit se sentir bien seul et impuissant dans le monde des humains, rendez-vous compte, vous leur dites des choses, et ils n'obéissent pas ! :)

La maîtrise d'une langue, et surtout sa propre langue est fondamentale pour permettre la réflexion. Il est tous aussi important de savoir passer d'un langage de programmation à un autre, savoir programmer dans une sorte de méta-langage applicable à n'importe quel langage de programmation.

Pour apprendre une langue, ou n'importe quel fait, il existe un outil bien intéressant et qui ouvre de nouvelle perspective d'apprentissage qui n'étaient pas possible ou pratique avant l'apparition de la micro-informatique. Il s'agit d'Anki (mot japonais signifiant "mémoriser"). Bien que cet outil soit écrit en python [1], il permet de travailler de façon continue et productive son apprentissage de faits, comme des mots de vocabulaire, des dates historiques, des bonnes pratiques, les principes sous-jacent à l'orienté-objet, etc.

La mémoire est volatile, c'est tout le problème. Si on ne se remémore pas les choses que l'on a apprises, on les oublie plus ou moins vite. Cela me rappelle les méthodes d'apprentissage énumérées dans l'excellent livre "Your Memory" de Kenneth L. Higbee, comme la méthode SQ3R :

- Survey : lire/apercevoir l'ensemble du document à mémoriser, la structure du document,

- Question : lors de cette prise de hauteur, se poser des questions sur chacun des points qu'on ne comprend pas, les noter quelques part,

- Read : lire ce que l'on veut mémoriser, répondre aux questions,

- Recite : réciter ce que l'on vient de mémoriser,

- Review : réviser ce que l'on a appris, se reposer les questions et y répondre par soi-même.

Ce qui est le plus important dans cette méthode, c'est la dernière étape : la révision ! Sans elle, aucun acquis, aucun apprentissage à long terme, aucun savoir ou savoir faire. C'est bien tout le problème, à l'école, des épreuves comme les devoirs surveillés, qui, une fois passés, peuvent être oubliés complètement par les élèves. C'est tout l'intérêt, (limité il est vrai) du baccalauréat qui vise à voir si l'élève a réellement assimilé les connaissances qu'il a apprises durant l'année (et pourquoi pas couvrir plus d'une année ?)

Anki permet de faire une révision progressive de toutes les connaissances que vous avez envie de maîtriser. Chaque jour, vous ne révisez que ce qui est nécessaire, l'outil calculant le meilleur moment pour vous faire réviser, en fonction de vos réussites précédentes de remémoration, comme il est dit sur le site d'Anki :
Anki se base sur une théorie appelée la répétition espacée. En termes simples, cela signifie qu'à chaque fois que vous révisez une matière, vous devez attendre plus longtemps que la dernière fois avant de la réviser à nouveau. Cela maximise le temps passé à étudier des matières difficiles et minimise le temps passé à réviser les choses que vous savez déjà.

Le concept est simple, mais la grande majorité des outils de mémorisation et des programmes de flashcards existants, soient évitent complètement le concept, soient implémente des méthodes loin d'être optimales qui étaient à l'origine conçues pour leur utilisation avec du papier et des crayons.
Personnellement, j'utilise Anki que pour la révision espacée, pas pour l'apprentissage proprement dit, car comme nous le dit très clairement Kenneth L. Higbee, un moyen de mémoriser profondément une matière est le surapprentissage : on continue à apprendre et réciter (répéter) au delà du moment où on a l'impression qu'on a assimilé la connaissance.

Utilisez-vous Anki ou d'autres moyens (flashcards...) pour vous remémorer des faits techniques relatifs à l'informatique ? Lesquels ?

[1] Faut le faire : python craint encore plus que Java, c'est dire ! :)

mardi 17 juin 2008

Firefox 3 : Comment préparer son serveur pour battre un record du monde

Aujourd'hui c'est le lancement officiel de Firefox 3. Alors je vais tranquillement faire ma BA et télécharger cette nouvelle version, notamment pour aider Mozilla Foundation à battre un record du monde de téléchargement en 1 seul jour.

Et bien, ça a du marché, ils ont du battre le record :



Un tel message nous apprend beaucoup de chose sur le monde en général (bien à propos en ces temps de baccalauréat de philosophie :) : La home page de mozilla-europe.org réalise un appel à MySQL alors qu'elle n'en a aucun besoin !

Est-il encore nécessaire de rappeler que, pour un site Web de gestion de contenu ou de gestion d'information au sens large, tout ce qui est non-fonctionnel (disponibilité, sécurité, performances, contraintes) est finalement bien plus important que le fonctionnel ! Le fonctionnel de telles applications est à peu près toujours le même, c'est de la publication d'information, voire du CRUD dans le pire des cas.

Franchement, aujourd'hui, rien ne sert de coder du fonctionnel quand il s'agit de gestion de l'information. Maintenant, les seuls points importants d'une application sont :

- l'Ergonomie,

- le respect des contraintes (disponibilité, sécurité, performances ...)

Dans tous mes projets, le plus important a été la définition claire et précise de l'exhaustivité des contraintes liées au projet et à ses produits. Et c'est là dessus qu'il y a le plus à gagner en terme de productivité.

lundi 16 juin 2008

Ni guru, ni hacker, arrêtons l’anarchie dans les routines : utilisons des assertions !

Le principal véhicule de la civilisation est le contrat, l’échange de promesses entre deux parties. Sans contrat, aucune confiance ne peut s’installer, aucun projet ne peut être concrétisé, chacun est dans son coin sans pouvoir compter sur personne.

En informatique on peut dire que c’est souvent l’anarchie dans le code source. Tout le monde veut utiliser tout le monde, toute routine s’arroge le droit de faire appel de n’importe quelle manière à tout autre routine qu’elle trouve dans son scope.

Dans le cas où toute les routines ont été conçues et construites pour être appelées de n’importe où et pour fonctionner sur n’importe quel environnement et dans n’importe quelle condition, il n’y a aucun problème. Or, ce n'est bien sûr jamais le cas.

Quand un développeur code une routine, il a en tête toutes les conditions nécessaires à son fonctionnement : les domaines de valeur possible des paramètres d’entrée, l’état actuel du système sur lequel elle fonctionne (comme par exemple le boutisme de la machine), la place mémoire et CPU disponible, l’état des variables globales à sa portée, les caractéristiques des valeurs de sortie…

Quand on est seul à coder une application il n’y a aucun problème. Dès qu’on est 2 ou plus à développer un même code, c’est l’anarchie [1]. Chacun imagine les conditions nécessaires de fonctionnement de chaque routine. Et pourquoi ne pas expliciter toutes ces conditions ? Pourquoi ne pas établir un contrat d’utilisation pour chaque routine ? L'idée d'utiliser des assertions semble dater d'un papier de C.A.R. Hoare de 1969 :

Sir Charles Antony Richard Hoare, professeur/chercheur britannique en informatique, créateur de la logique de Hoare et de l'algorithme Quicksort.

L'assertion est un des outils les plus utiles pour améliorer la qualité du code source, du point de vue de sa lecture, de sa simplification, de sa robustesse, de sa capacité de réutilisation, et de la facilité de son débogage. Or, c'est bien la technique que j'ai le moins rencontré dans les codes sources que j'ai été amené à lire ou auditer. C'est pourtant un moyen simple à comprendre et à mettre en œuvre. Et en plus, les conditions étant posées par le développeur, ce dernier peut se passer de traiter au niveau de sa routine toutes les conditions qui ne sont pas respectées. Chacun son métier, les vaches seront bien gardées !

[1] En fait, c'est à partir de 3 développeurs que c'est vraiment la galère comme la montré F.B. Brooks en 1975 dans son livre "The Mythical Man-Month". Le coût de la communication entre les développeurs augmente de façon quadratique : n(n-1)/2 : 3 développeurs nécessitent 3 fois plus de communications que 2 développeurs. 4 développeurs nécessitent 6 fois plus de communications que 2 développeurs...

vendredi 6 juin 2008

Vérification et correction grammaticale

Il y a, comme ça, des domaines dans l'informatique qui semblent ne pas avancer, voire même régresser. Il en va ainsi de la vérification grammaticale. Même s'il est vrai qu'il y a de nombreuses règles grammaticales et d'exceptions, il est quand même assez honteux que, de la part de Microsoft, l'éditeur qui s'autoproclame "innovant" et que tout le monde est obligé d'utiliser, on ait une régression au niveau de la vérification grammaticale dans Word :
Sous Windows, Microsoft Word ne fonctionne plus correctement depuis la version Word 97. Aucune nouvelle version du programme n'a pu trouver les erreurs dans les vingt phrases depuis Word 97.
Ce n'est pas nouveau, par abus de position dominante, Microsoft évite tout investissement dans ses logiciels, investissements qui ne lui rapporterais ni plus ni moins.


Les démonstrations de la faiblesse du correcteur grammatical de Microsoft Word sont légion sur le Web. Dans le monde "Open Source", il y a finalement peu de système de vérification grammaticale :

- An Gramadóir mais qui n'est qu'à l'état d'avancement sur la plupart des langages excepté l'irlandais.

- LanguageTool : il contient déjà pas mal de règles mais n'a encore qu'un très faible niveau de détection et de correction d'erreur (8% d'après l'étude ci-dessus). Il est utilisé par la suite OpenOffice.

Des logiciels payants existent, et semblent assez puissants. Pourquoi ne pas investir environ 300€ dans un tel logiciel et éviter des erreurs parfois lourdes de conséquence. Il y a beaucoup plus de solutions abouties de vérification orthographique, systèmes bien plus simples à concevoir. On peut facilement les intégrer dans n'importe quel éditeur extensible et customisable :


A ce qu'il paraît, l'orthographe et la grammaire se perdent (il y a surement plein de fautes sur mon blog). Microsoft Word n'améliore pas les choses, on a l'impression qu'on a un filet qui nous permet de ne pas nous concentrer sur notre écriture. Bah... on va pas en faire toute une histoire :)

Avez-vous déjà pensé à intégrer un tel vérificateur dans vos applications ? Des vérificateurs orthographiques existent pour Mozilla Firefox (par défaut à partir de la version 2) et une extension Internet Explorer existe.

mercredi 4 juin 2008

Problèmes de Satisfaction de Contraintes

Le rêve de tout développeur : que la machine fasse tout à sa place. Quoi de plus idéal que de pouvoir décrire son problème à un ordinateur et qu’il trouve la ou les solutions tout seul. Plus une ligne de code à développer ! Ce qui est paradoxal en informatique, c’est que le développeur véritablement paresseux est celui qui sera le plus productif. Le paresseux s’entoure d’outils les plus utiles pour avoir le moins de ligne de code à écrire. Un logiciel sans bug, c’est un logiciel sans ligne de code !

Un des outils les plus performants mais encore trop peu utilisé par les paresseux que nous sommes est l’utilisation de systèmes de résolutions de problèmes de satisfaction de contraintes (en anglais : « Constraints Satisfaction Problems solvers »)

Le domaine du traitement des contraintes s’articule autour d’une définition très simple :

- Soit X un ensemble de variables

- Soit D l’ensemble des domaines pour chaque variable de X

- Soit C l’ensemble des contraintes exprimées sur les variables X

Définir l’ensemble des solutions (affectation à chaque variable X d’une valeur de son domaine D) satisfaisant l’ensemble des contraintes C.

Ou alors, montrer qu’il n’y a pas de solution.

Ou alors, montrer quelle est la solution partielle la plus grande (le plus de variable de X affecté à une valeur et respectant l’ensemble des contraintes C)

Ou alors, montrer quelle est la solution complète ou partielle la plus satisfaisante d’après une fonction d’évaluation des solutions (une fonction de coût).

Autour d’une définition aussi simple, s’est construite toute une discipline de l’Intelligence Artificielle avec nombre d’algorithmes à la clé pour trouver toutes ces solutions. De nombreuses applications (comme par exemple la reconnaissance d'objet 3D à partir d'une scène 2D) et de "solvers" ont déjà vu le jour, mais l’usage d’outils de résolution de CSP (Constraint Satisfaction Problem) n’est pas encore aussi généralisé qu’on pourrait l’espérer.

En tant que développeur, on pourrait imaginer plusieurs applications de ces techniques :

- l’optimisation de l’administration des serveurs, notamment des serveurs de base de données (à ce propos, à partir de la version 10g d’Oracle Server, le système détermine par lui-même les meilleurs valeurs à appliquer aux variables de configuration, sans parler du CBO)

- la génération d’interfaces utilisateurs d’après une charge graphique exprimée sous la forme de contraintes.

- Un outil de gestion de projet de type MS Project mais où l’utilisateur ne fait qu’exprimer des contraintes et l’outil en déduit une ou des planifications (MS Project n’est pas très riche pour l’expression de contraintes réalistes).

On peut trouver des implémentations pour ce type d’application, mais on ne sent pas une généralisation de ceux-ci (on peut tout de même s’amuser à utiliser le solveur Excel pour faire de la résolution de contraintes…). Cela est surement du en partie à la difficulter pour le développeur moyen à entrer dans un domaine comme le traitement des contraintes.

Un livre complet sur le sujet et donnant une vue d'ensemble est "Constraint Processing" de Rina Dechter. On peut dire que ce livre est plus du côté de la science que du côté de l'informatique pratique qu'on rencontre en entreprise, mais qui peut s'attendre à un traitement correct du domaine sans passer par des définitions non ambigües et donc, mathématiques ?

Le traitement des contraintes est une technique qui a permi de prouver un théorème sans passer par une démonstration mais en explorant toutes les solutions possibles. Il s'agit du théorème des quatres couleurs
Dans les années 1960 et 1970, Heinrich Heesch s'intéresse à la possibilité de prouver informatiquement le théorème des quatre couleurs. Finalement, en , deux Américains Kenneth Appel et Wolfgang Haken affirment avoir démontré le théorème des quatre couleurs. Leur démonstration partage la communauté scientifique : pour la première fois, en effet, la démonstration exige l'usage de l'ordinateur pour étudier les 1478 cas critiques (plus de 1200 heures de calcul). Le problème de la validation du théorème se trouve alors déplacé vers le problème de la validation :
  • d'une part de l'algorithme d'exploration ;
  • d'autre part de sa réalisation sous forme de programme.
Utilisez-vous des systèmes de résolution de contraintes dans vos tâches quotidiennes ? Etes-vous prêt à essayer d'inclure un solveur dans un de vos prochains projets de développement ?

lundi 2 juin 2008

Dette technique - Technical Debt

C'est bien connu, une chose n'existe pas tant qu'elle n'a pas de nom. L'informatique, discipline pas si jeune que ça, n'échappe pas à la règle même si certains ont tendance à oublier certains noms pour en faire apparaître de nouveaux.

Voici un terme qui a l'avantage de mettre en avant un fléau difficile à cerner de notre discipline : la dette technique. Il s'agit de mettre un nom sur une pratique généralisée dans le métier et qui constitue le principal problème de maintenance des systèmes informatique. Une traduction de l'entrée wikipedia sur le sujet pourrait être résumée ainsi :
La dette technique est un terme inventé par Ward Cunningham pour décrire une situation où l'architecture d'un système logiciel est conçue et développée trop précipitamment. L'analogie avec une dette financière vise à montrer que du code écrit médiocrement requiert le "paiement d'intérêts" par un effort de maintenance, qui serait plus petit ou inexistant si le code fut développé plus soigneusement et avec une planification à plus long terme. Rearchitecturer et réécrire le code pour être plus maintenable est analogue au paiement de cette dette.
L'objectif d'une telle métaphore est bien de communiquer à des personnes qui n'ont pas de bagage technique mais qui sont pourtant en charge de l'allocation des budgets informatique, un problème essentiellement visible du développeur/architecte. La communauté des développeurs/architectes a tout intérêt à faire ressortir ces coûts dans l'objectif d'améliorer la qualité des logiciels et de rendre plus intéressant et utile la profession d'informaticien.

Cet article de scrumalliance.org montre bien la dette technique sur un graphe :


Mais un frein à la diffusion de cette information est le flou autour de ces coûts car la dette technique est à la base de la forte rentabilité des société de service en ingénierie informatique. Une SSII a tout intérêt a construire une application peu chère mais avec une forte dette technique pour qu'elle puisse continuer à faire de la marge sur la maintenance du système.

Je ne veux pas jeter la pierre aux sociétés de service, c'est grâce à elle qu'il y a tellement de travail dans ce domaine. Et puis on ne peut pas reprocher à une entreprise de viser la rentabilité maximum puisque c'est sa nature même.

Une des difficultés pour apprécier correctement la dette technique est la durée sur laquelle la dette va devoir être payée. Bien souvent la dette s'étale sur des années, souvent bien après la première livraison du logiciel. Sur plusieurs années, l'équipe de développement (ainsi que toutes les personnes autour) a du changer, voire même plusieurs fois.

L'article de Steve McConnell sur le sujet est bien instructif. Il essaie de classer les types de dette technique et d'en définir les aspects. Notamment le fait qu'on doit un jour ou l'autre rembourser ses dettes :

Une des plus importantes implications de la dette technique est le fait qu'elle doit être remboursée, i.e., une fois que vous avez contracté une dette, il y aura des intérêts à payer.
Si la dette grossie suffisamment, la société finira par dépenser plus pour le remboursement de sa dette qu'elle n'investira dans la croissance de la valeur de son capital. Un exemple typique est une base de vieux code ("legacy code") sur lequel il y a tant de travail pour maintenir le système en état de marche (i.e, "pour rembourser la dette") qu'il reste très peu de temps pour ajouter de nouvelle fonctionnalités au système. Avec une dette financière, les analystes parlent de "taux d'endettement", qui est égal à la dette totale divisée par l'ensemble du capital. Des taux d'endettement élevés sont vus comme étant risqués, ce qui semble également vrai pour la dette technique.
Ce qui est intéressant dans cet article, c'est l'idée qu'il peut être raisonnable de contracter une dette technique, pour des raisons commerciales notamment, chose que les développeurs ont du mal à comprendre. L'important est d'en avoir pleinement conscience et de rembourser un jour la dette pour qu'elle ne vous rende pas insolvable !

Le mieux, peut-être, pour faire apparaître la dette technique est de saisir un nouveau "bug" de type "dette technique" dans le système de suivi des défauts, portant sur ce qui n'a pas été fait correctement au niveau technique mais qu'il faudrait réaliser plus tard. Et puis, se fixer ensuite une règle du style : toute dette technique de plus de 90 jours doit être remboursée. Ce système de suivi de la dette peut être fait non seulement au niveau du code mais aussi au niveau de chaque activité du projet de développement sur laquelle un raccourci ou un compromis a été réalisé.

Enfin, la dette technique ne se retrouve pas uniquement en informatique mais dans tout domaine technique où un compromis sur un produit en augmente le coût de maintenance à plus ou moins long terme.

Suivez-vous votre dette technique ? Et de quelle manière ? Ou, trouvez-vous cela complètement inutile ?