Le document aborde la question de la dette technique dans le développement logiciel, soulignant la nécessité pour les équipes de reconnaître et d'évaluer la qualité de leur code. Il propose des méthodes pour améliorer cette qualité en impliquant l'ensemble de l'équipe dans des discussions sur les standards de code et en établissant des pratiques comme la refactorisation et les revues de code. Enfin, il insiste sur la responsabilité des développeurs dans la production de code de qualité et la nécessité de prendre des décisions conscientes pour réduire ou éliminer la dette technique.

1. La Solution à la Dette Technique
Etes-vous dans une équipe de développement logiciel, qui essaie d'être agile? La prochaine fois
que votre équipe sera réunie, demandez-leur:
Comment voyez-vous la qualité de notre code ?
Chacun notera alors cette qualité dans une échelle de 1 à 5, où 5 signifie “Elle est superbe, j'en
suis fier!” et 1 veut dire “Merde totale”. Comparez. Si vous voyez une majorité de 4 et 5, et rien
en dessous de 3, alors ne tenez pas compte du reste de l'article.
Si vous apercevez de gros écarts, par exemple des 5 et des 1, alors vous devez vous y pencher. Est
ce que les notes sont différentes sur des parties de code différentes? Si oui, pourquoi la qualité est-
elle si différente ? Est ce que les notes sont différentes sur le même code ? Si oui, que veut dire le
mot qualité pour chaque équipier ?
Cependant, il plus probable que vous voyiez plutôt un lot de 2 ou moins, et très peu de 4 et 5. Le
terme pour cela est Dette Technique, pour les besoins de cet article je vais simplement l'appeler
Code Crade (Crappy Code).
Félicitations, vous venez tout juste de révéler un grave problème ! Vous l'avez même quantifié. Et
cela vous a peine pris une minute. N'importe qui peut faire cela, vous n'avez pas besoin d'être
Coach Agile ou Scrum Master. Allez-y, rendez-le aussi claire que du cristal – dessinez les
résultats sur un tableau blanc, mettez-les sur un mur. Visualiser un problème est un grand pas vers
sa résolution!
Ne vous inquiétez pas, vous n'êtes pas les seuls, c'est un problème très courant. <rant>Cependant,
c'est un problème tellement stupide et inutile que je suis souvent déconcerté du pourquoi il est si
banale.</rant>
Maintenant vous avez besoin de vous poser certaines questions difficiles.

2. Est-ce que nous voulons l'avoir dans cet état ?
Si c'est non, qu'est ce qui définit la qualité de code que nous voulons? La plupart des développeurs
veulent un niveau de qualité entre 4 et 5. Oui, l'échelle est arbitraire et subjective mais elle est
toujours utile.
Si les opinions varient fortement alors vous devez avoir une discussion sur ce que vous entendez
par qualité, et où voulez-vous être en tant qu'équipe. Vous pouvez utiliser les 4 règles d'un code
simple de Kent Beck comme point de départ. Il est difficile de résoudre le problème si vous n'êtes
pas d'accord sur où vous voulez être en tant qu'équipe.
Quel est la cause de ce problème?
C'est juste une question rhétorique parce que la réponse est claire.
“Les choses sont comme elles sont parce qu'elles ont été obtenues de cette façon!” - Jerry
Weinberg
La merde se trouve dans le code parce que les développeurs l'y ont mise ! Permettez-moi d'être le
plus clair possible à ce sujet: Le code crade est crée par les développeurs. Le développeur
utilise le clavier physique pour salir le code réel dans son ordinateur réel. Indépendamment de
certaines circonstances, ce sont bien les actions du développeur qui déterminent la qualité du code
La première étape d'une résolution de dette technique est d'admettre et d'accepter ce fait.
“mais attendez, nous avons hérité de tout un tas de code crade. Nous ne l'avons PAS écrit!”
OK, très bien. La question pertinente dans ce cas est : “Est ce que la qualité du code s'améliore ou
s'empire?” Notez cela dans une échelle de 5 points (où 1 veut dire “s'empire très vite”, 5 veut dire
“s'améliore très vite”). Ensuite ré-appliquez cet article sur la base de cette question.
Pourquoi nous produisons du code crade ?
La réponse varie. Cependant, je l'ai posé plusieurs fois et j'ai vu de très fortes tendances.Ce n'est
probablement pas parce que vous VOULEZ écrire du code crade. Je n'ai jamais rencontré encore
un développeur qui aimait écrire du code crade.
Ce n'est probablement pas parce que vous ne savez pas écrire du code propre (ou nettoyé). Les
compétences peuvent varier, mais il suffit que vous ayez quelques personnes compétentes en
écriture de code propre dans l'équipe, et une volonté des autres à apprendre. Combinez cela avec
une habitude de revue de code ou de programmation par pairs, et la plupart des équipes seront
parfaitement capables d'écrire du code qui sera noté entre 4 et 5, s'ils prennent le temps dont ils ont
besoin pour cela.
Cela peut être dû au syndrome de la fenêtre cassée. Le code crade invite à encore plus de code
crade, parce que les gens ont tendance à adapter le nouveau code à partir de la qualité de celui qui
y est déjà présent (“quand on est à Rome…”). Une fois vous avez compris cela, vous pouvez
décidez simplement d'Arrêter ça, et de commencer à faire des revues de code, de la
programmation par pairs pour vous en protéger.
Cependant, la raison la plus probable sur pourquoi vous écrivez du code crade est: La Pression.
J'ai souvent entendu des commentaires du genre “On n'a pas le temps décrire du code propre”

3. (<rant>cette déclaration est au pire un mensonge, au mieux une excuse boiteuse</rant>). La
vérité, vous avez 24 heures par jour comme tout le monde, et c'est à vous de savoir ce que vous en
faites avec. Faites face à ça. Vous avez du temps pour écrire du code propre, mais vous décidez de
ne pas le faire. Maintenant continuons à examiner ce concept de Pression.
D'où provient la pression?
Vous pourriez vouloir faire une analyse de causes à effet. Est ce que le product owner vous met la
pression ? Pourquoi ? Qui met la pression sur le product owner ? Qui met la pression sur la
personne qui met la pression sur le product owner ? Dessiner la chaîne de pression.
Ensuite demandez-vous. Est ce que cette pression est réelle ? Est ce que ces personnes veulent
vraiment que nous écrivions du code crade ? Connaissent-ils les effets d'un code crade (Je parie
que vous pouvez en lister énormément), et pensent-ils vraiment que cela vaut la peine d'en écrire ?
Probablement non. Allez-y, levez-vous et allez demander.
Parfois la cause même de la pression est les développeurs eux-mêmes. Développer une
fonctionnalité prend presque toujours plus de temps que nous le pensons, et nous voulons
réellement être un BON développeur et rendre les parties prenantes contentes, alors la pression
s'accumule de l'intérieur.
REMARQUE: parfois il y a un sens "business" d'écrire du code crade. Parfois la dette technique is
Bonne. Nous avons peut-être un objectif court-terme très important et critique, qu'il faut atteindre
à tout prix, ou nous voulons peut être construire un prototype jetable pour tester rapidement le
marché. Mais cela doit être l'exception, pas la norme. Si vous nettoyer le bazar que vous avez mis
dès que l'objectif court-terme est atteint, ou que vous jetiez réellement le prototype, alors vous ne
finirez pas avec un cas chronique de code crade.
Devons-nous décider d'arrêter ce non-sens maintenant ?
C'est la question la plus importante.
Si vous êtes développeurs, le fait que vous (en tant que développeur) soyez responsable du
problème est en fait une Bonne Nouvelle. Parce que cela veut dire que vous êtes parfaitement
capable de Résoudre le problème. Et la solution est simple:
Arrêter d'écrire du Code Crade
(tout juste ce que le monde avait besoin – un nouveau sigle: SWCC™)
En anglais : Stop Writing Crappy Code
“mais mais mais mais mais…. on n'a pas le temps… le PO bla bla bla, la date de release bla bla”
Non, épargnez-moi vos excuses. Juste Arrêtez-ça.
Bien OK, vous pourriez effectivement décider de continuer à écrire du code crade. Vous pourriez
décider qu'il vaut mieux ne pas se battre dans cette bataille. C'est votre décision. Si oui, ne vous
faites pas appeler "équipe de développement agile" au moins, et contestez quiconque qui pourrait
penser que vous êtes agiles. L'un des principes fondamentaux du développement logiciel agile est
un Rythme Soutenable. Si vous créez constamment du Code Crade, le développement va devenir
de plus en plus lent avec le temps. Il n'y a pas de sens "business" dans ça, et ce n'est certainement
pas agile.

4. Mais en partant du principe que vous voulez arrêter, explorons ce qui arrive.
En tant qu'équipe de développeurs, vous pouvez prendre position: “Nous allons arrêter d'écrire
du code crade”! Ecrivez le sur le mur. Serrez-vous la main sur ça. Ajoutez “Ne plus ajouter de
dette technique” dans votre Définition de fini (DoD).
Dites au monde, et au gens en qui vous croyez et qui vous mettent la pression dans le codage:
“Nous avons écrit du code crade. Désolé pour ça. Nous allons arrêter maintenant.” Essayez de le
dire haut et fort. ça fait du bien !
Arrêter d'écrire du Code Crade
Regardez ces deux courbes.
Oui, c'est simpliste, mais la différence est réelle. Si vous continuez à écrire du code crade, vous
allez ralentir de plus en plus avec le temps (vous allez passer de plus en plus de temps à vous
battre avec le code existant). Si vous arrêtez d'écrire du code crade, vous aurez un rythme plus
soutenable. Mais il y aura un coût sur votre vélocité – vous irez moins vite à court terme.
En tant qu'équipe, vous décidez combien de travail vous pouvez planifier – que le principe de
planification par tirage (pull-scheduling) est fondamental dans Agile et Lean. Il est intégré dans
les méthodes agiles. Par exemple, dans la planification de Sprint de Scrum, l'équipe choisit
combien d'éléments du backlog elle peut tirer dans un sprint, comme sur le Planning Game de la
méthode XP. Dans Kanban, l'équipe a une limite de travail en cours (work-in-progress limit) et
tire seulement le prochain élément quand le courant est fini. Fondamentalement, l'équipe a tout le
pouvoir et la responsabilité sur la qualité. Utilisez votre pouvoir !
En terme concrets: Si vous faites du Scrum, et que vous livrez environ 8-10 fonctionnalités par
sprint, essayer de réduire ça. Mettez seulement 6 histoires au prochain sprint, malgré toute
pression perçue. Demandez-vous à chaque rétrospective. “Quelle est la qualité du code que nous

5. avons produit dans ce sprint (échelle 1-5)”. Si c'est moins que 4-5, alors tirez moins d'histoires
dans le prochain sprint. Continuez à faire cela jusqu'à ce que vous obteniez un rythme soutenable.
Cela a des répercutions coté "business" bien sûr. Le product owner (ou quelque ce soit la personne
qui fixe les priorités business) devra prioriser plus difficilement. Elle était habituée à voir 8-10
histoires sortir à chaque sprint. Maintenant elle verra seulement 6 ou 7, alors elle devra décider
quelles histoires ne PAS faire.
Oui, cela mènera à des arguments et discussions dures. La réelle source de pression (s'il y en a) se
révélera d'elle même. La Qualité est invisible à court terme, et cela doit être expliqué. Prenez la
bataille ! Restez fidèle à vos décisions. Si les développeurs ne veulent pas prendre la
responsabilité de leur code, qui le fera ?
La qualité du Code n'est pas la qualité du Produit
Le Code n'est pas tout. Il y a plus de gens impliqués dans le développement de produit
qu'uniquement les développeurs. Il y a les analystes métier, les testeurs, les managers, les
administrateurs système, les designers, les opérateurs, DRH, et plus.
Chacun est collectivement responsable de la qualité du produit qui sera fabriqué. Cela n'inclut pas
seulement le code, le design graphique, la structure de base de données, et les artefacts statiques
comme ça. Cela inclut aussi bien l'expérience utilisateur toute entière comme résultat business du
produit.
La qualité du Code est un sous-ensemble de la qualité du produit. Vous pouvez avoir un super
code, mais toujours finir avec un produit que personne ne veut utiliser car il résout le mauvais
problème.
Et vice versa – pouvez-vous avoir un super produit, mais avec un code crade ? J'ai horreur de
l'admettre mais, Oui, techniquement vous pouvez construire un super produit avec un code crade.
D'une certains manière, les équipes semblent s'en tirer parfois. Par contre, améliorer et maintenir
le produit est lent, coûteux, et difficile, parce que le produit est pourri de l'intérieur. C'est une
proposition perdant-perdant et sur le long terme les meilleurs développeurs partent.
Qu'en est il du vieux code crade (a.k.a Legacy Code)?
OK, alors vous venez d'arrêter d'écrire du code crade. Félicitations ! Vous venez d'arrêter
d'accumuler de la dette technique. Vous continuerez à payer des intérêts sur votre dette existante,
mais au moins la dette a arrêté de grossir.
La prochaine étape à décider – pouvez-vous vivre avec la dette technique existante, ou voulez-
vous faire quelque chose sur ça ? Si vous décidez de réduire la dette technique, la conséquence est
que vous allez ralentir encore plus à court terme, mais accélérer sur le long terme. Comme ceci:

6. Parfois cela en vaut la peine, parfois non. La réponse n'est pas aussi évidente, c'est une décision
business, alors assurez-vous d'impliquer les gens qui sont payés pour ça.
Si vous décidez de réduire votre dette technique courante, faites-en une décision claire: “Nous
allons arrêter d'écrire du code crade, et nettoyer progressivement le vieux code”.
Une fois que vous êtes d'accord sur ça (et c'est la partie difficile), il y a plein de techniques sur
comment faire. Voici deux techniques que j'ai vu marcher particulièrement bien:
1. Ajouter à la Définition de Fini: “Dette Technique réduite”. Cela veut dire dès que vous
fabriquez une fonction ou que vous touchez du code, vous le laissez dans un meilleur état
que vous l'avez trouvé. Cela peut être renommer une méthode pour la rendre plus claire, ou
factoriser certains bouts de code dupliqués dans une méthode partagée. De petites étapes.
Mais si l'équipe entière (ou encore mieux, toutes les équipes) fait cela constamment, la
qualité du code va s'améliorer significativement en quelques mois.
2. Pour les zones plus grandes à nettoyer, créer un “backlog technique” & un temps réservé
pour ça. Par exemple, listez le top 10 des zones d'amélioration et engagez vous à en corriger
un chaque semaine ou sprint, avant de construire de nouvelles fonctions.
Il suffit de garder à l'esprit que, si vous le faites, repayer la dette signifie moins de fonctionnalités
à court terme. Adaptez vos prévisions de vélocité de plans de release en conséquence. Comme tout
investissement, il y a un coût à court terme. Assurez-vous que chacun est clair sur ça.
Vous devez Ralentir pour Accélérer.
Mot de la Fin
Essentiel : la qualité du code est la responsabilité des gens qui écrivent réellement le code
(autrement connu sous le nom de Développeurs).
En tant que développeur, je suis responsable du problème, et je suis responsable de la solution. Il

7. n'est pas nécessaire de se fâcher ou d'avoir honte du passé. Au lieu de cela, rester fier et utiliser
votre pouvoir de faire quelque chose sur ça – prendre une lourde décision d'Arrêter d'Ecrire du
Code Crade (SWCC). Cela commence avec une chaîne d’événements et de bonnes choses vont
probablement suivre sur le long terme. C'est difficile et cela demande du courage, mais je connais
aucun autre moyen pour résoudre la dette technique.
Bonne chance!
/Henrik
FAQ
Est ce que la dette technique est toujours mauvaise?
Non. Avoir un peu de dette peut être bon. Voir mon autre article Bonne et Mauvaise Dette
Technique (et comment le TDD aide).
Le problème dont je parle ici est chronique, hors-de-contrôle, faisant grossir continuellement la
dette. J'ai vu tant d'entreprises se noyer dans de la dette technique, avançant lentement avec peine,
perdant leurs développeurs clés, et regrettant amèrement de ne pas avoir pris soin de la qualité de
leur code sérieusement dès le début, car ça coûte tellement plus cher de le réparer par la suite.
Couper la qualité donne des bénéfices court terme, mais le long terme est plus long que le court
terme, et la plupart des entreprises souhaitent survivre sur le long terme.
Qu'est ce que c'est la dette technique ?
N'importe quel bout de code & environnement de développement qui vous ralentit. Par exemple:
• Code illisible, pas clair.
• Manque de tests automatisés, de fabrication automatisée, de déploiement automatisée, et
tout autre chose qui pourrait être automatisé que vous faites manuellement aujourd'hui.
• Code dupliqué.
• Architecture bancale & dépendances complexes inutiles.
• Outils inefficaces, lents.
• Code non validé & branches longues (long-lived) (qui caches des problèmes qui pourrait
vous ralentir plus tard).
• Documentation technique importante qui manque ou n'est pas à jour.
• Documentation technique inutile qui est maintenue et gardée à jour.
• Manque d'environnements de test.
• Long cycle de test et de fabrication & manque d'intégration continue.