Construction de Théorie

Merci Arnaud pour ta contribution éclairante à cette conversation !

🎤 Est-ce que la "dette technique" n'est pas aussi, et même souvent, une situation analogue à celle du changement de paradigme décrit par Kuhn ?

🎤 Un logiciel ou système croît en fonction d'une certaine vision du monde, d'une certaine théorie sur comment il doit fonctionner, à qui il s'adresse, quels problèmes il doit résoudre, dans quel environnement il s'insère… Cette "théorie" initiale s'avère adéquate au début et permet de produire de la valeur, de donner satisfaction aux utilisateurs. Mais petit à petit, des failles apparaissent, des "faits" deviennent difficile à réconcilier avec la théorie. Les ingénieurs y parviennent avec de plus en plus de difficulté, ils prennent de plus en plus de temps pour chaque changement requis, et chacun introduit de nouveaux problèmes.

🎤 Pour réconcilier tous ces faits, il faut une nouvelle théorie (un nouveau cadre technique ou "état de l'art" comme tu le désignes) qui peut être plus ou moins différente, plus ou moins difficile à accepter (eg. passer d'un système centralisé écrit avec un 4GL et un SGBDR à des micro-services dans le cloud est certainement un changement de paradigme trop brutal).

🎤 Dans cette hypothèse, la dette technique est inévitable si le système doit s'adapter à son environnement.

Si je ne me trompe pas, tu empruntes à Peter Naur, autre lecteur de Kuhn, sa vision de la programmation comme construction de théorie. La conclusion de son essai peut éclairer notre lanterne sur la DT :

📖 Si l'on accepte qu'une part essentielle de la programmation consiste à apporter au programme les modifications requises par un changement des circonstances extérieures, alors il faut admettre que le but primordial en programmation est de faire en sorte que les programmeurs construisent une théorie du problème à résoudre tel qu'il est supporté par l'exécution du programme. De cette considération découle la notion que la vie d'un programme dépend des programmeurs qui possèdent la théorie de ce programme. […]

📖 Une autre conséquence de ce point de vue est que les programmeurs doivent se voir accorder le statut de développeurs responsables et managers perpétuels de l'activité dans laquelle l'ordinateur joue une part, et que leur éducation doit mettre en avant l'exercice de la construction de théories, à côté de l'acquisition des connaissances du traitement de l'information et des notations.

Cette prescription émise en 1985 (!) n'a pas été entendue, loin de là : notre activité est gérée non par 1 mais 3 acteurs (Métier, Tech, Management), et le drame qui se joue naturellement entre eux représente une source indirecte mais permanente de dette technique.

Je voudrais donc compléter ta conclusion : la dette technique est inévitable si le système doit s'adapter à son environnement sans le support continu d'une équipe intégrale qui en construit et étend la théorie.