- Le niveau d’un développeur ne se résume pas à ses connaissances : même en sachant ce qu’il faut faire, remettre à plus tard les tests, le refactoring ou la rédaction de cas de reproduction par manque de motivation finit par accumuler de la dette technique
- Les excellents développeurs enquêtent sur les flaky tests et les corrigent, transforment les bugs découverts en tickets ou les corrigent immédiatement, et lorsque de nouvelles fonctionnalités s’accordent mal avec le code existant, commencent par refactorer
- Des maximes comme “premature optimisation”, “duplication is better than the wrong abstraction”, “Keep It Simple, Stupid” sont utiles pour traiter de vraies contraintes, mais peuvent aussi servir à masquer un simple manque d’envie
- Pour Lazygit, un système de tests end-to-end a été construit sur plusieurs mois et son efficacité a été clairement ressentie, mais les mêmes tests n’ont pas été ajoutés à Lazydocker, tandis que la demande d’un dépôt minimal de reproduction et le refactoring d’une God Struct ont aussi été repoussés
- Même lorsqu’on n’a pas l’énergie d’écrire un code parfait, exposer honnêtement ce qui manque permet de juger plus facilement des critères de maintenance et des priorités pour la suite
Le manque de motivation qui crée de la dette technique
- “Can’t Be Fucked” est un argot australien qui désigne l’état dans lequel on n’a pas envie de faire quelque chose, ou bien on manque de l’énergie et de la motivation nécessaires
- On peut penser qu’apprendre davantage de connaissances techniques suffit pour devenir un meilleur programmeur, mais en réalité, les développeurs que l’on finit par admirer sont ceux qui possèdent non seulement du savoir, mais aussi une rigueur constante
- Les bons développeurs savent qu’il vaut mieux traiter correctement les problèmes quand ils sont encore petits, car cela fait gagner du temps à long terme
- s’il y a un flaky test, ils l’analysent et le corrigent
- s’ils découvrent un bug en conditions réelles, ils créent un ticket ou le corrigent immédiatement
- si une nouvelle fonctionnalité s’intègre mal au code existant, ils refactorent d’abord au lieu de la forcer à entrer
- si nécessaire, ils descendent jusqu’aux couches les plus basses de la stack pour identifier la cause
- Ces développeurs savent aussi distinguer les cas où “good enough” est approprié, ceux où il faut réduire le périmètre, et ceux où il vaut mieux apprendre davantage sur le domaine avant de modifier l’architecture
- Le problème, indépendamment de ce jugement, est qu’à certains moments le manque de motivation devient une contrainte plus forte que les contraintes externes du projet
Être honnête au lieu de se cacher derrière des maximes
- Le système de tests end-to-end de Lazygit a été construit à temps partiel sur plusieurs mois, a ensuite empêché de nombreuses régressions, et il est convaincant de penser qu’il serait bien plus difficile de l’ajouter maintenant
- malgré cela, la seule raison pour laquelle des tests end-to-end n’ont pas été ajoutés à Lazydocker est simplement le CBF
- Après avoir ouvert une issue dans un autre dépôt open source, une demande de dépôt Git minimal de reproduction a été faite, mais il n’a toujours pas été créé ; de même, un grand refactoring entamé il y a plus d’un an n’a toujours pas été terminé, si bien qu’une grande partie du code reste encore dans une God Struct
- L’auteur ne tranche pas sur la question de savoir s’il s’agit de burnout, d’un manque de growth mindset ou d’un trait de personnalité
- Savoir à quel point la douleur à long terme de la dette technique est grande peut motiver l’évitement, mais savoir et agir réellement de la bonne manière sont deux choses différentes
- Des phrases comme “trop de tests créent une charge de maintenance”, “je refactorerai après avoir vu l’impact des autres fonctionnalités”, “premature optimisation”, “cut scope aggressively” peuvent relever d’un bon jugement, mais aussi servir d’excuses
- Si l’on admet qu’une partie du code ou d’une pull request est insuffisante par paresse, le reviewer peut alors juger directement si cette insuffisance dépasse le seuil acceptable, ou s’il vaut mieux consacrer du temps à la tâche suivante
- Quand l’état de CBF arrive, mieux vaut être honnête que se décourager, et si l’on a tourné à 100 % trop longtemps, il est peut-être temps de prendre des vacances
1 commentaires
Avis sur Hacker News
Une grande partie du CBF peut s’expliquer simplement par la rémunération et les incitations
Quand je suis arrivé dans cette entreprise, j’étais plein d’énergie : je réparais les builds cassés, je faisais passer les tests laissés à l’abandon, je refactorais le pipeline de déploiement et je trouvais puis corrigeais les causes profondes des bugs
Mais avec le temps, au lieu de prendre exemple sur moi, les gens se sont mis à penser « de toute façon, cette personne va le corriger », et j’ai compris que faire les corvées ne faisait que m’attirer davantage de corvées
À l’inverse, ceux qui bricolent des solutions à la va-vite emballent bien les résultats, obtiennent une promotion en premier, et quand les problèmes explosent en production, ils sont déjà passés à un autre projet
Le junior que j’aide plusieurs heures chaque semaine gagne plus que moi parce qu’il a été recruté en urgence en 2022, et moi, en 2023, j’ai reçu une évaluation « au-delà des attentes », mais aucune augmentation sous prétexte que la période était difficile
Au final, du point de vue de quelqu’un qui travaille contre un salaire, si les efforts ne sont pas récompensés, voire deviennent une punition, il n’y a rien d’étonnant à ce que la motivation disparaisse
Il faut partir, trouver l’endroit qui vous correspond et vos propres gens
Quand on est reconnu, ce coût baisse fortement, et les gens aiment être récompensés
Si les gens passent des milliers d’heures sur des jeux, c’est aussi parce que le coût de la motivation y est très faible
Je ne dis pas qu’il faut gamifier le travail, mais comme se défendre soi-même donne l’air mesquin, les collègues devraient se reconnaître mutuellement
La dette technique a elle aussi différents taux d’intérêt, et la compétence consiste à laisser de côté la dette à 0 % pour rembourser d’abord celle à fort intérêt
En posant le sol du placard au sous-sol, je suis tombé à court de matériaux et je n’ai pas pu finir complètement le fond. Ce n’est pas très joli, mais c’est toujours caché par des cartons et cela n’aura aucun impact même après des décennies. C’est une dette technique à 0 %
En revanche, si une gouttière est bouchée, plus le temps passe, plus le coût augmente à cause d’infiltrations au sous-sol ou de la chute de la gouttière : c’est une dette qui porte intérêt. Des marches d’entrée abîmées qui font trébucher en permanence sont aussi une dette à fort intérêt à réparer rapidement
En ingénierie, un problème d’architecture qui ralentit tout développement de fonctionnalités peut être une dette à fort intérêt, tandis que du code sale ou des TODO dans un fichier qu’on touche rarement peuvent, en pratique, être une dette à faible intérêt
Les ingénieurs passent parfois à côté de travaux plus importants parce qu’ils réparent une dette à 0 %, tout en disant que « le produit/la direction ne soutient pas le traitement de la dette technique », alors qu’ils n’expliquent souvent pas bien le coût réel ni le taux d’intérêt
De haut en bas, seules les choses nouvelles et brillantes attirent l’attention, et personne ne s’intéresse à la maintenance de l’existant
Même si l’on parvient à convaincre de son importance, la direction se contente d’admettre que le travail est nécessaire, mais cela n’a aucun impact positif sur l’évaluation de performance. Et si ça tourne mal, c’est moi qui me retrouve à porter une tâche pour laquelle je ne recevrai que des reproches
Si une codebase est sale et incohérente, même dans des fichiers cachés, les développeurs auront moins envie d’implémenter de nouvelles fonctionnalités avec cohérence et qualité
On finit par se dire : « de toute façon, il faudra réécrire tout ce module, donc collons ça ici vite fait et on nettoiera plus tard »
https://en.wikipedia.org/wiki/Broken_windows_theory
C’est une extension naturelle de l’expression dette technique, et cela transmet l’idée essentielle de façon concise, au point que j’aimerais l’utiliser en entreprise
Donc reprocher au développeur de ne pas avoir expliqué le coût réel est une excuse un peu facile
Si un problème visible par les clients apparaît, il a des chances d’être résolu, mais s’il ne s’agit que d’un problème interne, ces chances diminuent fortement
Quand on commence à employer sérieusement des expressions comme « dette technique à 0 % », il faut peut-être se demander si le concept n’est pas mal cadré
Une dette doit être remboursée ou produire des intérêts ; si ce n’est pas le cas, ce n’est pas une dette
La prochaine étape, ce sera de dire qu’une fonctionnalité pas encore implémentée est aussi une dette technique à 0 % ?
Je ne suis pas fan de Steve Jobs, mais j’ai toujours aimé sa citation sur l’artisanat et l’attention aux détails
« Si vous êtes un menuisier qui fabrique une belle commode, vous n’allez pas mettre du contreplaqué au dos, même s’il est tourné vers le mur et que personne ne le verra. Vous saurez qu’il est là, donc vous utiliserez aussi un beau bois pour l’arrière. Pour dormir tranquille la nuit, l’esthétique et la qualité doivent aller jusqu’au bout »
Je pense que le logiciel dans son ensemble souffre beaucoup de l’attitude qui consiste à dire : « j’ai tout juste satisfait techniquement les exigences, donc mon travail est terminé »
https://www.goodreads.com/quotes/445621-when-you-re-a-carpen...
Il refusait de lancer du matériel et du logiciel qui n’atteignaient pas le niveau requis, et il y a beaucoup d’histoires selon lesquelles il licenciait ceux qui n’arrivaient pas à produire selon les bonnes spécifications
À l’inverse, la plupart des gens travaillent sous un leadership exactement opposé : « finissez aussi vite que possible pour vendre davantage, et contentez-vous d’ajuster à peu près ce qu’il faut pour passer les tests qualité »
Un vrai menuisier doit être pragmatique et rentable pour être compétitif sur le marché
S’il utilise du bois coûteux ou passe du temps sur des parties que personne ne voit, son débit baisse et le coût pour le client augmente inutilement
Même pour un artisan, le temps et l’argent sont limités, et le temps passé sur ce qui ne se voit pas est du temps qui n’est pas consacré à ce qui se voit davantage
Sur un marché où des menuisiers de même niveau produisent plus à moindre coût, un tel menuisier serait évincé
Je pense que le problème du logiciel relève davantage des incitations que de l’attitude. J’aime faire du bon travail et utiliser du bon logiciel, mais le temps dans une journée est limité, et je ne vais pas sacrifier mon temps personnel pour un bénéfice business dont je ne profiterai pas
De plus, si je commence un refactoring, je peux raisonnablement m’attendre à ce qu’une fonctionnalité indispensable à terminer dans la journée apparaisse soudainement
Même si la direction accepte de traiter la dette technique, au final rien ne sera résolu à moins de gonfler les estimations de planning et de faire du refactoring à la place du travail assigné
Dans un livre, un forgeron qui répare une pièce de chariot dit : « faites toujours du mieux que vous pouvez »
Quand on lui répond : « mais c’est une pièce qui va dessous, personne ne la verra », il réplique : « mais moi, je sais qu’elle est là. Si je ne fais pas aussi bien que je peux, j’aurai honte chaque fois que ce chariot passera. Et je verrai ce chariot tous les jours »
https://news.ycombinator.com/item?id=28086786
Si vous écrivez de vrais tests unitaires, d’intégration et end-to-end, et que, face à du code en bazar, vous le refactorez au lieu d’empiler encore par-dessus, votre productivité sur le papier sera inférieure à celle d’un collègue qui continue de « résoudre » des tickets
C’est particulièrement vrai dans les organisations « full agile » qui ne prennent absolument pas en compte le refactoring ni la qualité du code
Apple a été une exception, au moins à une époque. Ses produits étaient chers, les clients attendaient de la qualité, l’entreprise avait les marges nécessaires pour la rendre possible, et surtout il y avait Steve Jobs, qui avait l’œil pour l’expérience
À l’extrême opposé, on trouve des cas comme Juicero, qui a construit une machine pour presser des sachets de jus avec une ingénierie de niveau aérospatial
Pendant la majeure partie de ma carrière, je nettoyais la dette technique dès que j’en voyais l’occasion, même sans qu’on me le demande. Parce que j’avais de l’attachement et un sentiment de propriété
Aujourd’hui, dans un environnement de travail sans autonomie et fondé sur la microgestion via Jira, je ne fais rien en dehors du strict nécessaire
Avant, l’effort volontaire était au cœur de ma carrière, mais désormais le coût bureaucratique et social de gestion de projet de n’importe quel changement est tellement élevé que cela ne vaut pas la peine
Que le produit réussisse à long terme ou que l’entreprise réussisse ne m’intéresse plus ; je me contente de traiter des tickets jusqu’à trouver mon prochain poste
À l’inverse, si l’on procède en mode « ne demandez pas la permission pour refactorer », on se fait reprendre parce qu’on a ouvert une PR qui ne suit pas les patterns existants du dépôt
Cela devient : « c’est bien, mais il faut en discuter avec toute l’équipe »
Résultat : la dette technique continue de grossir, fusionner une seule PR prend des mois, et les tests sont tellement instables que cela ressemble à une machine à sous de casino où l’on appuie sur redémarrer jusqu’à ce que ça build. L’agile est vraiment formidable
Dans un lieu de travail qui ne fonctionne qu’en réaction, agir de manière proactive n’a jamais été récompensé d’après mon expérience
Si je découvre un problème, il devient immédiatement mon problème, et s’il réapparaît plus tard, c’est moi qui l’ai cassé
Les PM et le management partent toujours d’hypothèses négatives, donc ça n’en vaut pas la peine
En particulier, certains pensent avoir trouvé la voie éclairée vers du bon code, alors qu’en réalité ils choisissent souvent un chemin plus facile que lire et comprendre le code existant
Il y a pas mal de malentendus dans les commentaires ici
Pour un programmeur individuel, la motivation, l’effort, l’énergie, la volonté — quel que soit le nom qu’on leur donne — sont des ressources limitées, et c’est tout à fait normal
L’avantage d’une organisation est d’accomplir plus qu’un programmeur seul, mais lorsqu’on assemble plusieurs éléments, des interstices apparaissent et le travail tombe entre les mailles
Les personnes payées pour faire fonctionner l’organisation plutôt que pour produire du travail technique, comme le COO, les RH ou les product managers, devraient créer des processus pour traiter ces interstices
Pourtant, de plus en plus d’entreprises rejettent ce travail sur chaque ingénieur et designer, parce qu’il est difficile à mesurer via le P&L ou les OKR
L’entreprise en souffre et les ingénieurs finissent en burn-out. Il y a une limite au fait de continuer à s’occuper des petits tickets et des tâches tombés entre les mailles sans compensation supplémentaire
L’ambiance ici est très négative, mais j’ai été content de lire ce texte parce qu’il décrit exactement ce que je ressens au quotidien
Quand je vois l’excellente couverture de tests et les refactorings menés avec principes dans des projets open source, certains jours je passe moi aussi en mode « faisons ça correctement » et j’arrive à produire beaucoup de choses bien faites
Puis, un jour, cette énergie disparaît et, comme l’auteur, je passe en mode CBF. Je saute les tests, j’ajoute du code à un endroit dont je sais qu’il n’est pas bon, et je prépare un chemin dont mon moi futur ne me remerciera pas
Je vois tout ça se produire en temps réel, mais je n’ai ni l’énergie ni la motivation pour revenir à ce mode inspiré « faisons ça correctement »
Et tout cela arrive même dans des logiciels que je crée et vends moi-même
J’ai été impressionné de voir que l’auteur est la personne qui a créé Lazygit, et j’aime vraiment lazygit. Dans ma tête, il fait clairement partie de la catégorie des mainteneurs open source qui font toujours les choses correctement
On dirait qu’on vit tous les deux des choses assez similaires en matière de motivation
Je suis content que tu aimes lazygit, et j’espère pouvoir continuer à mériter cette bonne opinion
La plupart des décisions sont en réalité inconscientes
L’état « vraiment pas moyen » signifie qu’un circuit du cerveau juge que des tâches comme le refactoring ou les tests ne valent pas la peine d’être faites
Et ce circuit peut avoir raison. Objectivement et globalement, la récompense n’est souvent pas suffisante par rapport à l’effort
Par exemple, si tu as passé deux mois à construire des tests de bout en bout et que, sur les six mois suivants, cela t’a fait gagner trois semaines en débogage et autres, le calcul ne tient pas
Il y a deux extrêmes courants. D’un côté, le business impose aux ingénieurs de la dette technique qui est vraiment un mauvais compromis ; de l’autre, les ingénieurs passent parfois du temps sur une structuration idéale et d’énormes suites de tests qui ne seront finalement pas récompensées
Une partie vient aussi de la crainte que quelqu’un repère une meilleure structure de code ou des tests supplémentaires et vous juge là-dessus
Quand j’ai l’impression de livrer quelque chose qui n’est pas à la hauteur de mes standards, même si ces standards sont plus élevés que le besoin réel, cela abîme fortement le moral et la motivation
À mon avis, le plus gros problème de la dette technique, c’est justement qu’elle détruit le moral
Pour Lazygit, j’ai passé plusieurs mois à construire partiellement un système de tests de bout en bout, et je pense chaque jour aux régressions qu’il a évitées et à la difficulté qu’il y aurait à l’ajouter maintenant
Je sais très bien que cela en valait la peine, mais si je n’ai pas ajouté de tests de bout en bout à Lazydocker, c’est simplement parce que CBF
Les tests de bout en bout sont une galère infernale et un travail énorme quand les outils ne sont pas au niveau. Il faudrait de meilleurs frameworks de base qu’on puisse intégrer facilement
Avec un peu de chance, cette personne aura encore du temps pour s’occuper des tests d’intégration
Je trouve que, dans cette société et dans ce monde, la façon dont on voit les gens comme paresseux est globalement absurde
On est censés travailler 40 heures par semaine pendant des décennies, puis se reposer seulement après s’être réincarnés, et on voudrait parler de paresse dans ce contexte ?
Notre énergie mentale est extraite pour fabriquer la richesse d’autrui, puis on nous jette quand on devient trop vieux pour faire quoi que ce soit
Chaque semaine, une nouvelle fonctionnalité qui aurait dû être finie hier arrive, alors quand est-on censé corriger la dette technique ? Sur notre temps libre ? Je ne sais même pas pourquoi on devrait continuer à exister, à la base
Dans un projet mature au sein d’une petite équipe, tous les tickets restants étaient des bugs difficiles dont personne ne voulait
Même après plusieurs jours d’effort, on n’avait rien à montrer à part quelques pistes suspectes écartées, et parfois on les écartait à tort pour les voir revenir une semaine plus tard
Chaque jour, il fallait consacrer toute son énergie mentale à ce genre de tickets, et quand, à force de café ou de stimulants, on finissait par corriger un bug, il fallait soumettre le code, fermer le ticket, puis passer immédiatement au suivant
Il n’y avait pas de vrai repos ; au début du ticket suivant, on pouvait juste reposer un peu son cerveau, tant que personne n’attendait encore de résultat immédiat
Mais au bout de quelques jours, les gens demandaient ce qu’on avait fait jusque-là, si on était bloqué, et il fallait inventer de petits mensonges pour expliquer pourquoi on était en retard alors qu’en réalité on avait à peine commencé
Au moment où on a le plus besoin de repos, on est déjà le plus en retard et les gens l’ont remarqué, donc même prendre des congés ne ressemble plus à une option
Aujourd’hui, je travaille dans une organisation d’ingénierie à but non lucratif, 20 à 30 heures par semaine, parfois moins, et l’argent est serré, mais travailler davantage m’est tout simplement impossible
J’ai un peu de temps pour des projets perso et pour faire du vélo, et je ne travaille jamais le week-end. Je ne travaille pas non plus le mardi, sauf cas particulier
J’aime vraiment mon poste actuel, c’est le job de mes rêves, mais il ne vaut pas la peine de me tuer à la tâche. On n’a qu’une vie, et je vais la vivre en aimant pleinement
Aujourd’hui, j’ai terminé un chantier d’un mois qui a consisté à réécrire presque entièrement le firmware d’un appareil de l’entreprise, alors qu’au départ il était estimé à une semaine pour corriger un petit bug dans une partie du module de communication
Heureusement, j’ai un PM et des collègues détendus, qui reconnaissent que cela permet maintenant de corriger réellement des bugs legacy vieux de huit ans dans ce code
Il reste encore des tests de cas limites et des corrections supplémentaires, mais comme les mises à jour de code à distance fonctionnent, on peut expédier les appareils
Ici, « mentir » est plutôt une recommandation d’action. À l’origine, j’avais commencé mon commentaire par « mentez », mais il y a eu un malentendu
C’est aussi pour rappeler à nos collègues qu’il est important de prendre le temps de réfléchir aux implications plus larges du travail
Et c’est pour apporter ses pensées à des communautés comme celle-ci, manger du chocolat, promener un chien si possible, et écouter des conférences d’Alan Watts sur YouTube
En tant que personne qui essaie de bien faire les choses, je pense que l’important avec la dette technique, c’est le suivi
Il suffit de quelques minutes pour créer une tâche à partir d’un problème visible, et cette tâche devient de la dette technique
La direction a la responsabilité de prioriser la dette technique et d’en réduire continuellement une certaine quantité
Parfois, on réduit aussi la dette technique en décidant de ne pas faire quelque chose, et c’est tout à fait acceptable
Le but du processus consistant à consigner, vérifier et traiter, c’est de donner une deuxième chance d’examiner les problèmes qui sont « pas pour maintenant »
La première intuition pouvait être fausse et X pouvait ne pas être nécessaire ; à l’inverse, elle pouvait être juste pour des raisons auxquelles on n’avait pas pensé à l’époque
Surtout, parmi les choses qu’on se dit « impossibles à faire maintenant », certaines sont réellement importantes. Si on ne prend pas le temps de les examiner, on ne peut pas les trouver