Dans l’introduction du livre The Pragmatic Programmer, on trouve un chapitre intitulé Stone Soup And Boiled Frogs. Les auteurs y évoquent la célèbre métaphore des grenouilles bouillies :

Si vous plongez des grenouilles dans l’eau froide, puis que vous augmentez progressivement la température de l’eau, les grenouilles resteront tranquillement à leur place jusqu’à se trouver complètement cuites lorsque l’eau sera bouillante. En revanche, si vous jetez une grenouille directement dans l’eau bouillante, celle-ci trouvera immédiatement la force de s’extraire de ce milieu hostile.

Dans le présent article, je vais m’appuyer sur cette métaphore pour développer l’idée selon laquelle la dette technique est susceptible de produire un environnement similaire à celui dans lequel sont plongées les grenouilles malheureuses.

En me basant sur mon expérience, j’ai pu constater que certains faits générateurs de dette technique ont un impact négatif réel sur le psychisme des acteurs qui y sont confrontés, et je pense tout particulièrement à ceux qui sont au coeur du métier du développement; les développeurs eux même.

De la dette technique à la dette psychologique

Le concept de dette technique commence à être bien connu dans le monde du développement logiciel et les professionnels l’invoquent de plus en plus pour alerter sur les stratégies court-termistes que l’on est parfois tenté de mettre en place.

Dans la formule dette technique, le terme le plus fort est évidemment celui de dette. C’est la vraie trouvaille conceptuelle de cette formule. Une dette est un passif dont il faudra s'acquitter dans le futur mais auquel on ne peut pas se soustraire. Il est aussi admis que la dette est inévitable; c’est un phénomène naturel (pensons à la notion d’investissement qui s’accompagne de dettes) qu’il convient tout simplement de maîtriser.
Une dette technique qui ne se résorberait pas peut même conduire à un phénomène de surendettement technique; une situation dans laquelle tout effort technique sert à payer les intérêts de la dette.

Ceci étant bien compris, le terme technique a finalement moins de poids dans ce concept. Tout le monde se rassure en pensant que la technique, on en vient toujours à bout. On trouvera bien un jour le magicien qui détient la recette miracle ou alors on jettera et re-écrira tout.

Cependant, il est un effet de la dette technique qui est plus difficile à prendre en considération car il ne s’agit justement pas de technique; c’est l’effet qu’elle induit sur la psychologie et donc le comportement des acteurs clés de notre industrie. J’ai nommé les développeurs.

Donc si nous revenons à nos grenouilles, le rôle de la marmite d’eau qui chauffe sera joué par la dette technique et le rôle de grenouilles sera joué par les développeurs.

Quand la température augmente, les développeurs s’épuisent

La dette technique rend l’expérience des développeurs plus pénible et le travail plus laborieux. j’ai donc tendance à penser que ceux qui subissent la dette technique au plus tôt, ce sont les développeurs eux-mêmes.

Maintenir un code trop vieux ou mal écrit, utiliser un framework de développement ne répondant plus aux besoins du moment, ne pas disposer des bons outils, être dans l’incapacité de faire un diagnostic ou de tester son code sont des expériences frustrantes qui vont mettre progressivement les développeurs dans un état de malaise.
Les effets sur le moral sont réels.

• Découragement
• Lenteur
• Baisse de motivation (Bore-out)
• Perte de créativité
• Érosion des compétences

Des ressentis négatifs peuvent induire des comportement néfastes pour le bon fonctionnement de l’équipe

• Défiance
• Aigreur
• Résistance
• Individualisme

Finalement, on constatera que la dette technique tend à immobiliser les développeurs, à leur retirer toute capacité d’action comme les grenouilles incapables de trouver l’énergie pour s’extraire d’un milieu dont elle ne se rendent même pas compte qu’il va finir par les tuer.

L’épuisement des facultés des développeurs se répercute de façon amplifiée sur l’équipe. Alors que le métier du développement nécessite de plus en plus d'interactions, d’échanges et de dynamisme, la dette technique tend à tuer le travail d’équipe et l’esprit de collaboration.

Au niveau du management, on est souvent conscient des problèmes de dette technique d’une part, des problèmes humains d’autre part. Mais mettre ces deux phénomène en relation n’est pas si facile. Il n’est pas aisé de se mettre à la portée des développeurs; quand on rentre dans le management on perd rapidement pied d’avec la technique.
Par ailleurs, les technologies évoluant très rapidement, les managers sont perpetuellement confrontés aux demandes de renouvellement des développeurs.

Il est fréquent de voir s'installer un climat de défiance entre les développeur et leur management; les développeurs étant soumis à la dette technique, les managers quant à eux ayant du mal à évaluer les impacts de cette dette technique sur l'organisation.
Ces conditions transforment l'environnement en marmite d'eau bouillante; la situation s'aggrave mais on ne sait pas ce qu'il faut faire, alors on ne fait plus d'effort.

Pourquoi ce phénomène doit-il être pris en compte ?

En observant l’évolution du monde du développement depuis plus de dix ans, l’impact de la dette technique sur les développeurs m’est apparu de plus en plus nettement et je suis maintenant convaincu qu’il s’agit d’un nouveau phénomène qui doit être pris très au sérieux à un niveau stratégique.

Le phénomène de dette technique n’est pas nouveau bien sûr mais le regard que l’on porte dessus est en train de changer. La dette technique apparaît de plus en plus comme un élément qui peut perturber l’écosystème informatique dans son ensemble et plus seulement d’un point de vue purement technique. A mon sens, cela est fortement lié à deux phénomènes : la prolifération d’innovations technologiques et l'émergence d’une nouvelle génération d’informaticiens.

Le marché de l’emploi en informatique est tendu car la révolution numérique tire une croissance importante alors que le nombre de développeurs sur le marché est insuffisant.
Dans ce contexte, les technologies de développement évoluent à une vitesse vertigineuse et les développeurs sont particulièrement sensibles aux phénomènes d’obsolescence de leurs compétences. En conséquence, la dette technique est un repoussoir pour eux.

Dans la situation actuelle, en ignorant la dette technique on fait fuir les développeurs créatifs et motivés tout en épuisant progressivement les développeurs que l’on a su fidéliser. Dans un contexte où l’exigence d’innovation est croissante, ne pas inclure le facteur dette technique dans sa stratégie de développement peut être suicidaire.

Certains acteurs du numérique ont bien compris ces enjeux. Ce sont des structures au sein desquelles on sait valoriser la qualité, le goût de l’innovation, et l'amélioration en continu des compétences.

À mon sens, il est tout à fait envisageable que l’on assiste dans les décennies à venir à une forme de transfert des compétences vers les sociétés pour qui la dette technique est un concept pris en compte à un niveau stratégique.

Quelques illustrations concrètes

Jusque-là nous en sommes restés à des considérations très générales. Afin d’apporter quelques arguments concrets à cette réflexion, je vous propose d’illustrer le propos au travers de trois phénomènes générateurs de dette technique.

L’obsolescence technologique

Vous êtes visionnaire, vous vous lancez dans un tout nouveau projet de développement et vous avez confiance en vous. Tout va très vite dans le monde du numérique : les premiers succès sont là, vous montez en charge, une armée de développeurs est maintenant sur le pont et tout le monde a la tête dans le guidon.

Oui mais tout va très vite (on l’a dit déjà ça). En cinq ans, une nouvelle techno émerge, fait le buzz et les choix technologiques du début sont maintenant dépassés. Certes, mais peu importe : ça marche encore !
Cependant que constatez vous autour de vous ?
Des concurrents viennent vous damer le pion avec des trucs plus modernes, plus séduisants. Vos développeurs qui se sont investis durement au long des années se plaignent du vieillissement technologique. Vous n’arrivez plus à recruter les talents dont vous avez besoin pour développer votre activité.

Quelle ingratitude ! Alors que vous avez fait progresser consciencieusement la richesse fonctionnelle de votre solution logicielle, vous avez perdu progressivement votre capacité productive.

Que s’est-il passé ?

Vous avez peut-être négligé de prendre en compte l’exigence du renouvellement technologique.

Une technologie dépassée peut ne pas sembler présenter un grand péril de prime abord, mais va provoquer très progressivement les effets négatifs suivants :

• Votre solution va paraître vieillotte voire ringarde aux yeux de vos clients, ou prospects indépendamment de sa valeur intrinsèque.
• Votre solution aura de plus en plus de mal à s’intégrer aux autres composants du système d’information et aura du mal à répondre à de nouvelles exigences telles que la sécurité, l’automatisation, la disponibilité, la résilience, la scalabilité.
• Vos développeurs vont se lasser de ce projet et en perdre petit à petit leurs capacités créatives et productives.
• Il va être difficile de faire évoluer vos équipes car votre technologie ne sera plus en phase avec celles qui sont porteuses sur le marché de l’emploi.

Dans le cadre de cet article, c’est particulièrement le ressenti des développeurs qui me préoccupe, vous l’aurez compris.

Les développeurs en place depuis longtemps sont insatisfaits, mais ne trouvent pas nécessairement la force de l’exprimer. Ils se sont investis de longue date. Ils ont la tête dans le guidon. Ils n’osent pas remettre en question toute la structure.
En somme, ça ne se voit pas forcément, mais ils ont perdu peu à peu leur énergie productive.
Ils montent des usines à gaz pour se désennuyer. Ils paraissent très occupés, mais ne font finalement qu'aggraver une situation dans laquelle la productivité, l’innovation et la valeur du produit s’érodent.

A contrario, si vous tentez de mettre en place de nouveaux développeurs pour relancer la dynamique créative, ceux-ci prendront vite leurs jambes à leur cou ou se laisseront rapidement cuire comme les autres (c’est affaire de tempérament).

Le conseil

Ne vous laissez jamais endormir par l’idée que le vieillissement technologique de votre solution n’a aucun rapport avec sa valeur intrinsèque.

Veillez à ce que cette solution évolue avec son temps et ayez confiance dans vos développeurs pour assurer ce renouvellement. Il est inutile de chercher à remplacer des grenouilles cuites par des grenouilles fraiches qui de toute manière ne le resteront pas longtemps dans une eau déjà bouillante ; évitez plutôt de tuer vos développeurs à la tâche.

La pauvreté de la conception et la mauvaise qualité du code

KISS, Keep It Simple Stupid !

Ce principe à mon sens vaut pour le kick off d’un projet. On est guidé par la créativité. Il faut convaincre vite. Il faut du concret. Mais qu’en est-il lorsque que votre solution a plusieurs années et quelques centaines de milliers de lignes de code legacy ?

Faute d’une conception solide, mûrement élaborée, vos développeurs vont à la longue passer leur temps à patauger dans un code redondant, verbeux, peu évolutif et finiront par se laisser cuire dans un environnement de développement où la moindre ligne de code demande tellement d'énergie intellectuelle qu’ils en oublieront ce à quoi elle sert exactement.

Si au bout d’un temps, vous en prenez réellement conscience, vous chercherez une solution dans la “reconception”. C’est à ce moment que vous amènerez vraiment l’usine à gaz chez vous. Vous ne manquerez pas de développeurs frustrés qui vous expliqueront que c’est conçu avec les pieds depuis le début et qu’il faut tout réécrire, mais que ça risque de prendre un certain temps qu’il est impossible d’évaluer à l’instant présent.

Le conseil

Ne négligez pas la conception au départ du projet (et surtout pas au nom de l’agilité, ce qui serait un contresens).

Faites appel à des architectes, des experts, des développeurs expérimentés. Même s’ils vous font peur avec des discours conceptuels, ou qu’ils donnent l’impression de passer trop de temps à réfléchir, ils sont les garants de l’assise de votre solution.

Pratiquez en continu les bonne pratiques de développement que sont la factorisation et la relecture de code.

Et surtout, valorisez la qualité du code. Le développement est une discipline complexe qui requiert un gros effort intellectuel.

Même si on a trop souvent utilisé cette analogie simpliste, le développement d’un logiciel, ce n’est pas l’assemblage de briques. Le développement ce n’est pas une tâche au sens où on l’entend dans l’organisation du travail taylorisé.
Un logiciel étant par essence une abstraction, sa qualité est difficile à évaluer et les effets d’une mauvaise qualité peuvent se faire ressentir tardivement.

Le manque ou l'absence de tests automatisés

Il y a encore trop d’organisations qui restent convaincues que le développement de tests automatisés représente un coût prohibitif dont on peut très facilement faire l’économie.

Certes les tests automatisables sont complexes à mettre en œuvre et demandent un véritable investissement intellectuel. Cependant leur mise en place est un facteur clé dans la résorption de la dette technique.

Un développeur qui ne peut pas tester facilement son code va développer un comportement d'autocensure. Le mécanisme est simple : si l’on ne peut pas tester on ne prend pas le risque d’améliorer le code, de refactoriser ou reconcevoir et de faire évoluer les frameworks et outils.

Les risques de régression étant trop grands, il est plus naturel de rester dans le confort. Cependant en même temps que la dette technique s’accumule, les développeurs perdent progressivement leur capacité d’action ; ce qui représente une double peine pour votre logiciel.

Le conseil

Développez des tests automatisables !

Le testing est une des disciplines les plus complexes du développement. C’est tout à fait paradoxal, car les tests, en apparence, ne produisent rien et demandent un effort important.

Conclusion

La dette technique, c’est la gangrène du développement logiciel.

Si le concept de dette technique commence maintenant à être assez souvent mis en avant dans les organisations, il est encore difficile de prendre en compte l’impact humain. Or le monde du développement change vite et les pratiques managériales sont en pleine mutation. Le regard que l’on porte sur les métiers du développement commence à changer. Il me semble donc important de porter la réflexion autour de la dette technique à un niveau managérial.

Le phénomène de dette est inévitable et il faut apprendre à vivre avec. Je suis pour ma part convaincu que, dans l’industrie du développement logiciel, les structures qui survivront seront celles qui en auront pris conscience et qui auront su mettre en œuvre une réelle stratégie de résorption de la dette technique s’appuyant sur les piliers suivants :

• L'amélioration continue.
• La confiance dans la capacité créative des développeurs.
• L’exigence en terme de qualité.
• Le testing.

Enfin, pour clore cet article, permettez-moi simplement de citer The Pragmatic Programmer :

Don’t be like the frog. Keep an eye on the big picture. Constantly review what’s happening around you, not just what you personally are doing.