Contre-Effet de Levier

Bienvenue Mauko Quiroga Alvarado dans cette conversation ! Merci pour cette réflexion :

Pour moi la dette technique c'est une CAPEX, c'est un choix volontaire et rationnel avec un engagement de remboursement. Soit tu la paies, soit c'est un/e autre qui le fait. L'exemple classique du client à forfait qui ne veut pas de tests : il paie moins cher en échange de dette technique. Si on sait bien ce qu'on fait (presque jamais), cela peut être même un choix justifié.

et ces questions :

A quoi fais-tu référence par dette technique ?

Je fais référence à la métaphore inventée par W. Cunningham, qui signifie dégrader la conception temporairement afin d'atteindre un objectif intermédiaire. Dans le cas mentionné dans mon post comme une "factory" de dette :

 remplacer les expressions logiques en court-circuit par des ifs imbriqués

la direction Qualité dégrade localement l'état de l'art [Programmation en C] dans ses standards en vue (croit-elle) de prévenir des situations de comportement non spécifié.

Qu'est-ce que la Direction de la Qualité achetait en échange de cette dette?

Elle achète, mais sur la base d'un diagnostic erroné, de la prévention de défauts.

Quel aurait-pu être le choix ?

Il est possible que la DQ ait considéré un maintien de la restriction tant que l'état de l'art des compilateurs C ne serait pas "amélioré" par les éditeurs. J'ai souvent attendu que le monde remédie à des problèmes qui existaient seulement dans mon jugement, aussi je ne leur jetterai pas la pierre.

En général, une équipe, un service, ou une organisation qui pose une limite sur les constructions disponibles dans un langage ou une technologie donnée, comme par ex :

  • les appels de fonction récursifs sont interdit
  • les vues SQL sont interdites
  • la programmation orientée objet est interdite

crée une dette technique en échange d'une simplification de ses objectifs.

Elle dégrade un état de l'art : par exemple elle proclame (ou plutôt écrit) :

  • goto est interdit

afin d'éviter à l'entreprise des situations dans lesquelles une conception reposant sur des gotos manque de clarté ou de fiabilité.

Comme aime à le rappeler Laurent Bossavit, abusus non tollit usum (nous n'avons pas proscrit l'usage du latin dans notre état de l'art chez CodeWorks, mais nous pourrions considérer de le faire :-). L'abus n'empêche pas l'usage. Mais une direction de la Qualité a besoin de régulateurs. Son objectif est d'institutionnaliser autant que possible les états de l'art ayant cours dans l'entreprise, afin de pallier à deux problèmes massifs en informatique :

  • la volatilité des technologies

  • le déséquilibre entre la demande en personnes compétentes en technologie comme en savoir-faire et les capacités de notre système d'enseignement supérieur.

L'ironie rattrappe la DQ quand son propre état de l'art, lequel inclut la veille technologique, est lui-même dégradé. L'effet de levier se retourne alors contre l'entreprise.

Stay Tuned !