- Lorsque le taux d’utilisation de l’usine a baissé de 10 %, l’entreprise a voulu constituer des stocks avant la haute saison plutôt que licencier ; une demande a donc été lancée pour faire passer la limite de backlog de 3 mois à 4 mois
- Le responsable IT pensait qu’il suffisait de modifier une seule valeur codée en dur dans une routine cœur, mais il fallait d’abord créer un ticket, renseigner l’impact métier, obtenir une approbation et ajuster la priorité dans la file
- Le programmeur a changé la valeur
MonthsOfBacklogde"3"à"4"à la ligne 1252 du module ORP572 et les tests sont passés, mais la revue de code a ajouté à corriger des violations de politiques existantes - Le périmètre du changement s’est élargi à des procédures annexes : transformer la valeur en enregistrement dans le fichier Parameters, supprimer des commandes de debug, traiter un avertissement de variable non assignée, un Employee ID codé en dur, les droits d’accès, l’environnement de test, le plan de test et la signature utilisateur
- Le changement nécessaire au métier tenait à 1 ligne et 1 octet, mais le délai total a été de 6 jours ; les procédures et politiques internes ont fortement allongé le lead time réel d’une petite modification
Demande de passage de la limite de 3 mois à 4 mois
- Philip, le président, indique que l’usine est sous-utilisée de 10 % et souhaite produire davantage de backlog pour constituer des stocks avant la haute saison plutôt que procéder à des licenciements
- Lee, responsable des opérations, explique que la politique de l’entreprise ne permet de produire que jusqu’à 3 mois de backlog ; passer la limite à 4 mois créerait donc suffisamment de travail
- David, responsable IT, estime qu’il suffirait probablement de modifier une seule ligne de code dans une routine cœur du logiciel legacy, et demande de soumettre un ticket à IT Services
- Judy, responsable IT, affecte la demande au
Ticket# 129281, mais indique que la section Business Impact et l’approbation d’un Director sont nécessaires- Lorsque David évoque la possibilité de licenciements, Judy remplit elle-même cette section et fait passer la demande en traitement accéléré
- Deux jours plus tard, la demande est toujours dans la Developer Queue, premier Enhancement derrière 14 Bug Reports
- David demande de marquer la demande comme urgente et de l’envoyer directement à Ed
Comment une modification d’une ligne devient un changement de procédure
- Ed modifie la variable codée en dur
MonthsOfBacklog, de"3"à"4", à la ligne 1252 du module ORP572- Les tests unitaires passent et il exécute deux tests batch
- La file de travaux d’Operations augmente bien de 10 % comme prévu
- Le changement passe en Code Review et en User Acceptance Testing auprès de Homer
- Shirley, chargée de la revue de code, estime qu’une variable codée en dur contrevient à la politique de l’entreprise et exige d’en faire un enregistrement dans le fichier Parameters
- Elle indique aussi que deux anciennes commandes Debug, un avertissement de variable non assignée et un Employee ID codé en dur doivent être corrigés avant la mise en production
- Comme ORP572 a été assigné à Ed, elle considère qu’il est aussi responsable des erreurs existantes qui violent la nouvelle politique de l’entreprise
- L’environnement de test devient lui aussi une source de retard
- Homer est indisponible à cause des tests de contrôle de clôture comptable de fin de mois ; il faut donc utiliser Marge
- Ed n’a pas les droits d’accès à Marge, et Joe, de l’IT Security, indique qu’il ne peut pas les accorder sans la signature de David
- Le travail sur l’enregistrement Parameters s’étend avec de nouvelles exigences
- Le nom
MonthsOfDemanddoit être amélioré, au motif qu’il serait difficile à comprendre pour des programmeurs à l’étranger - Le nouvel enregistrement Parameter doit disposer d’une piste d’audit, mais cette politique n’est pas documentée et la mise à jour du wiki a déjà trois mois de retard
- Ed renomme le champ en
SelectedMonthsOfBacklogDemandet ajoute le module PAR634 pour maintenir cet enregistrement et sa piste d’audit
- Le nom
- Tony, chargé des tests, remarque que
129281apparaît dans Marge, mais qu’il n’y a pas de Test Plan- Ed explique qu’il suffit d’exécuter l’ancien et le nouveau mode puis de vérifier l’augmentation du total dans le rapport
WorkOrdersHours, mais Tony répond que cela affecte toute l’usine et exige des Test Cases sélectionnés par l’utilisateur, des Expected Results, des Test Runs documentés et un sign-off utilisateur - Deux jours plus tard, Philip ordonne à David de faire en sorte que Tony mette immédiatement le programme d’Ed en production
- Ed explique qu’il suffit d’exécuter l’ancien et le nouveau mode puis de vérifier l’augmentation du total dans le rapport
- Le temps écoulé total est de 6 jours, alors que le changement de mission critical code portait sur 1 ligne et 1 octet
- 24 Excedrin ont été consommés
- Le temps passé sur Hacker News en étant agacé est indiqué comme étant de 14 heures
1 commentaires
Commentaires sur Hacker News
Le point essentiel, c’est que le relecteur a exigé que « pour changer ça, il faut aussi corriger d’autres problèmes non résolus du codebase »
Dans ce genre de cas, il faut répondre : « L’objectif d’améliorer la qualité du code est bon, mais si on change Y, il faut des validations X/Y/Z et cela prendra encore plusieurs jours. Ce que vous mentionnez, nous allons en faire un travail de dette technique et le traiter dans une PR de suivi selon la priorité et la capacité disponible. Pour l’instant, concentrons-nous sur ce qu’il faut pour déployer cette PR localisée. »
La plus grande leçon apprise, c’est de faire des PR ciblées et de savoir répondre quand un relecteur essaie d’élargir le périmètre. En général, les autres ingénieurs l’ont pris de manière pragmatique. Cela n’a rien à voir avec le nombre de lignes. On peut reformater tout le code sans changer la logique, ou n’ajuster que quelques feature flags avec un impact important. Il faut ne faire qu’un seul changement ciblé à la fois
Si c’était vraiment une priorité si élevée qu’il fallait jusqu’à licencier des gens si ce n’était pas traité tout de suite, ces 2 à 3 jours avant qu’une personne le voie n’auraient jamais dû exister. Pourtant, dans ce processus de développement, cela semble être la « voie rapide »
Les 2 derniers jours semblent aussi n’avoir mené à rien, parce que le plan de test a été jugé insuffisant. « Il faut aussi corriger d’autres problèmes non résolus pour changer ça » n’a occupé que 2 heures ici, et même avant cette partie il y avait déjà au moins 2 ou 3 autres éléments à pointer comme problèmes majeurs de ce processus
Plutôt que de laisser un FIXME ou un TODO, j’essaie de créer discrètement un ticket pour ne pas oublier. Cette partie de la review est cassée. La résolution de la dette technique ne doit pas être une condition d’achèvement du travail, elle doit être planifiée séparément
À force d’empiler ces couches, le code finit dans un état moralement équivalent à Atlanta, en Géorgie, tristement célèbre pour ses rocades
Quand une nouvelle règle est ajoutée, l’automatisation devrait ajouter des commentaires d’exception à toutes les violations existantes, tout en les rendant traçables. Si du code à déployer en urgence doit enfreindre la règle, il suffit d’ajouter un commentaire d’exception et d’y associer son propre nom comme responsable de la correction ultérieure
Avec le temps, on peut créer une culture où l’on corrige ces violations de règles séparément du développement de fonctionnalités
C’est vrai. Le processus de code review de la plupart des entreprises est rempli de pinaillement et de commentaires insignifiants
J’avais proposé autrefois de remplacer ce genre de commentaires par des outils d’analyse statique pour supprimer ce bruit et accélérer le feedback, mais on m’a répondu que ce type de code review était nécessaire pour tout le monde. Cela aide les gens à être promus, leur donne l’impression d’avoir empêché des problèmes dans le code, et permet aux managers de plus haut niveau de regarder le nombre de commentaires de review pour faire paraître les métriques de code review meilleures
La vraie solution, c’est d’accepter que tout le code n’a pas besoin de ressembler à quelque chose que j’aurais écrit moi-même, et de se demander : « Est-ce que ce commentaire traite une erreur objective dans le code ? » Souvent, la réponse est « non »
Si le nom d’une variable est un peu verbeux ou si l’espacement entre les méthodes est irrégulier, idéalement cela devrait devenir un « feedback à garder en tête la prochaine fois si cela devient une habitude ». Mais du point de vue du relecteur, le nombre de commentaires par PR peut être vu comme une métrique de son accompagnement, ou il peut craindre une réaction du type « qui a laissé merger ça ? », donc il finit par laisser un commentaire
La personne qui reçoit la review modifie alors le code, soit parce qu’elle craint de paraître peu réceptive au feedback si elle ne traite pas le commentaire, soit parce qu’elle pense qu’en contestant elle risque une mauvaise évaluation du relecteur. Il faut alors faire réapprouver la version mise à jour, et le cycle de retard recommence
Mais certains problèmes considérés comme insignifiants par certaines personnes ne le sont en réalité pas du tout. Cela peut venir du fait qu’elles ne voient pas le problème de leurs propres yeux, ne le comprennent pas, ou n’ont pas la capacité de mettre leurs émotions de côté pour repenser le code qu’elles ont écrit
Nous avons tous déjà été attachés au code que nous avons écrit, et peut-être pensé qu’il était le plus élégant du monde. Mais parfois, il faut admettre que nous avions tort, qu’il est difficile à lire, défectueux et nuisible au codebase
Il m’est déjà arrivé de signaler une condition de concurrence potentiellement réelle dans le code de quelqu’un de plus senior que moi, et de me faire traiter de pinailleur. Pour moi, une condition de concurrence est un problème fondamental du code, qui doit être corrigé ; pour cette personne, c’était acceptable tant qu’elle ne l’avait pas encore vu se casser de façon évidente
J’aime beaucoup la review par les pairs et je me concentre généralement sur : « ce code ne se comportera pas comme prévu », « cette approche bloquera l’implémentation ou la rendra bien plus coûteuse », « ça fonctionne, mais c’est difficile à comprendre et cela nuira à la maintenance ; il faut envisager une autre approche ou ajouter des explications », et « le code est correct, mais il pourrait être plus lisible ou mieux fonctionner ; cela ne justifie pas un refus de la review, mais c’est utile à garder en tête pour le prochain code »
« Julie : contactez Joe de l’équipe sécurité IT. Il vous donnera les droits. Dans 2 heures. » est totalement irréaliste. L’équipe sécurité ne répondra jamais aussi vite
npm installet déclenché une alerte de sécurité P1J’en viens parfois à me demander si les agents du helpdesk ne se jettent pas dessus dès qu’il arrive pour améliorer leurs métriques personnelles avec un ticket qu’ils peuvent fermer rapidement
Dire, comme dans le titre, qu’il faut 6 jours pour changer une ligne de code semble terrible
Mais le système s’est amélioré de plusieurs façons. La configuration est devenue paramétrable via une table de paramètres plutôt qu’en dur, et une fonction d’audit permettant de tracer ces changements de configuration a aussi été ajoutée
Je ne cherche pas à défendre la bureaucratie. Je déteste sincèrement cet aspect des grandes organisations. Je veux simplement souligner qu’en plus de l’objectif initial, de la valeur supplémentaire a été créée pendant ces 6 jours
C’est pourquoi il faut intégrer une certaine quantité de coûts annexes dans les estimations, et si l’on attribue des story points, il faut aussi tenir compte de ces coûts de procédure
Au final, les deux accomplissements ont été : l’« accomplissement » d’avoir évité le cérémonial supplémentaire autour des changements de code, puis l’« accomplissement » d’avoir récupéré à l’avenir la fonctionnalité perdue avec le premier « accomplissement », puisque ce changement ne passera plus par le code
Il aurait fallu dire : « C’est urgent, merci d’accepter cette PR d’un seul caractère. Les améliorations demandées ont été mises dans un ticket de suivi. Réglons d’abord le problème de production, et nous traiterons le reste ensuite »
Le relecteur n’avait plus qu’à répondre « LGTM! ». Si la plupart des ingénieurs sont incapables de naviguer entre les règles et les recommandations, alors l’organisation est folle, et c’est précisément là que la seniorité a de la valeur
Si cela peut prendre une semaine sans affecter l’emploi de qui que ce soit, alors il faut suivre le processus ou ne changer que le strict minimum. Si des gens sont en chômage technique non rémunéré à cause de l’IT, alors toutes les personnes nécessaires doivent être dans la même salle, physique ou virtuelle, jusqu’à résolution du problème
Ce contexte n’apparaît pas ici. Mais si Ed et toute la chaîne d’approbation ne connaissaient pas ce contexte, alors c’est un échec du système. S’ils avaient su que le loyer de quelqu’un était en jeu, un senior aurait probablement proposé d’ouvrir un deuxième ticket pour corriger proprement ensuite. Sinon, c’est aussi un problème que la direction doit résoudre
Cette histoire est un cas où un changement d’une ligne avec une valeur codée en dur s’est en réalité bien passé
On peut imaginer un scénario où quelqu’un a stocké le nombre de mois de backlog sur 2 bits pour avoir l’air malin et intelligent. Du genre : seules les valeurs 0, 1, 2, 3 sont possibles. Pendant les tests, le problème peut ne pas apparaître parce qu’il est caché plusieurs couches plus bas, dans un sous-service non testé ou un service d’automatisation low-code
Si l’on change cette valeur en 4, le backlog peut tomber à 0. Impossible de savoir ce qui se passera. Le service pourrait annuler toutes les tâches de la file de production, ou envoyer aux clients des e-mails annonçant l’annulation de leurs tâches
En apparence, cela ressemble à un changement facile, mais si un changement de politique a été transmis à l’équipe logicielle comme un problème urgent, alors c’est à la direction de mieux planifier, pas de bouleverser arbitrairement la priorité des sujets
Au contraire, on a augmenté le risque en exigeant, comme « coût » du changement, de refactoriser plusieurs éléments périphériques
Ce serait bien que le grand patron dise : « Je décide d’assumer le risque et d’aller de l’avant, et j’en accepte aussi les conséquences. » Il vaudrait mieux que ce ne soit pas les programmeurs qui aient raison
S’il s’agissait d’une mise à jour importante et sensible au temps sur une fonctionnalité critique, le responsable opérationnel aurait dû connaître le temps moyen de déploiement du logiciel, et au lieu de l’envoyer dans le pipeline de développement normal avec une haute priorité, il aurait dû constituer une équipe dédiée au traitement accéléré
La revue de code part d’une bonne intention. Mais il finit toujours par y avoir un gardien de porte qui s’installe et commence à tout rejeter pour des raisons mineures
Il affirme se soucier de la « qualité du code ». Pourtant, il n’y a rien de pire que de laisser trop longtemps en place un code bogué déjà corrigé, ou de retarder une fonctionnalité au point que personne ne puisse l’utiliser
J’approuve les commentaires, mais je recommande un processus dans lequel le relecteur ne peut pas bloquer un commit. Il faut faire confiance à chaque développeur pour être prudent et effectuer des changements adaptés à la tâche. On peut aussi utiliser la CI, et selon les équipes, tout cela peut très bien fonctionner
Changer le processus pour qu’on puisse simplement ignorer un relecteur pathologique n’est, au mieux, qu’une demi-mesure
Quant au blocage, je suis partagé. Je comprends qu’un gros blocage rouge soit frustrant, donc dans beaucoup de cas je ne bloque pas et je demande simplement des changements, un « blocage souple ». Mais quand une PR a complètement déraillé, en général avec un développeur junior, je pense qu’il est approprié d’envoyer un message clair
C’est une réflexion méta sur les ouvriers d’usine et les développeurs logiciels
Le dirigeant de cette entreprise est prêt à licencier des ouvriers d’usine pour 10 % de sous-utilisation. On peut ajuster quelques variables pour améliorer la productivité, mais au bout du compte le choix, c’est utilisation complète ou chômage. C’est probablement possible parce que ces ouvriers sont remplaçables, qu’on peut les réembaucher en haute saison, et que le profit généré par employé ne permet pas de tolérer l’inefficacité
Moi, je travaille comme développeur logiciel. Dans notre secteur, il faut largement dépasser 90 % de sous-utilisation avant même d’envisager de faire partir quelqu’un. Beaucoup de gens ne travaillent que 4 heures par semaine. Personne ne suit nos minutes ni nos pauses toilettes
Nous sommes actuellement dans une période de capitalisation massive du logiciel. Cela ne durera pas éternellement. Un jour, l’infrastructure principale du monde IT sera en place et le secteur passera en mode maintenance. La plupart d’entre nous ne seront plus nécessaires, deviendront remplaçables, et le profit que nous générerons dans ce mode maintenance sera minime comparé à ce qu’on voit aujourd’hui
Les ouvriers d’usine sont généralement licenciés en quelques minutes ou quelques heures si leur productivité individuelle est perçue comme faible. Je pense que nous verrons cela commencer aussi pour les développeurs logiciels de notre vivant
Il faut aussi évaluer dans quelle mesure cela peut s’appliquer à votre propre ensemble de compétences
Je suis d’accord avec l’idée de fond selon laquelle la capitalisation massive du logiciel ne durera pas éternellement. Toutes les entreprises n’auront pas toujours besoin d’ingénieurs pour développer de nouveaux logiciels. C’est plus proche d’une activité créative avec des cycles d’expansion et de creux, comme la production cinématographique, que de l’IT. Si l’on choisit le développement plutôt que l’IT, il faut accepter ce risque. En revanche, je ne vois pas pourquoi maintenant devrait être le sommet
D’expérience personnelle, après avoir passé quelques années dans une équipe avec des revues de code formelles, je suis passé dans une équipe/entreprise sans revue de code. Tout le monde pouvait librement commit et merge sur n’importe quelle branche
J’avais des sentiments mitigés en arrivant, mais en pratique c’était très rafraîchissant et responsabilisant, au point de devenir productif en quelques jours
push and prayVu les objectifs de l’équipe, l’absence de revue de code convenait très bien. C’était un groupe R&D dont l’objectif principal était de faire des démos de « nouvelles fonctionnalités sympas » aux dirigeants. Il y avait beaucoup de demandes de dernière minute, mais aussi beaucoup de code jeté
Après une démo, un dirigeant disait « ça a l’air bien, mais il n’y a pas de viabilité commerciale », puis le dépôt n’était plus jamais touché. Bien sûr, il arrivait parfois que ce qu’on construisait finisse en produit, et dans ce cas une sous-équipe avait la responsabilité de transformer notre code griffonné en qualité production. Ces gens nous détestaient d’une haine ardente
Les nouveaux membres de l’équipe se voyaient attribuer un mentor qui s’asseyait à côté d’eux pendant les 2 à 3 premiers mois, faisait souvent du pair programming et relisait leur code
C’était un projet de 2,5 ans, mis en production au 20e mois, livré dans les délais et dans le budget, avec plus de fonctionnalités que prévu au périmètre initial. Bien des jours, on passait 2 à 3 heures à discuter devant un tableau blanc. C’était informel, et tout le monde ne participait pas systématiquement
Curieusement, trois PM se sont succédé pendant ce projet. Il y avait une règle stricte : pas d’e-mails ni de sollicitations en dehors du stand-up, et deux des trois n’ont pas réussi à « travailler » dans ce cadre. Le responsable IT de l’aéroport n’a compris qu’au bout de deux ans que nous n’avions pas besoin de PM
Il y avait une règle disant qu’il fallait parler à au moins un autre développeur avant d’entreprendre un nouveau travail dans la codebase. Nous étions assis à quelques pas les uns des autres dans de grands bureaux individuels avec de grands tableaux blancs. Les stories étaient gérées avec des fiches sur un tableau blanc dédié, et si on ne pouvait pas y expliquer l’essentiel, il fallait la découper en morceaux plus petits
Chacun montait sa propre machine et pouvait utiliser autant d’écrans qu’il le souhaitait. Il s’agissait du système de facturation et de tarification d’un grand aéroport international, et la responsable comptable, le directeur, ainsi que d’autres utilisateurs se trouvaient à quelques portes de bureau de nous. Ils ne manquaient presque jamais le stand-up et avaient une politique de questions en temps réel ouverte en permanence
Le stand-up était généralement une discussion informelle, une démo ou des questions-réponses, pas un reporting d’état. Pour les mises à jour de statut, il suffisait de regarder les fiches sur le tableau blanc
Le système final a amélioré les revenus de 8 % dès le premier mois puis chaque mois suivant. Le directeur comptable devait l’expliquer devant le conseil d’administration de l’autorité aéroportuaire. Les litiges et rapprochements de facturation avec les compagnies aériennes sont passés de 9 jours par mois à 1 jour, et la charge de travail mensuelle de facturation de 18 jours à 5 jours. Ils ont pu confier l’utilisateur principal non plus à un comptable senior, mais à un seul comptable junior avec 3 ans d’expérience
Il y a eu 6 bugs de production la première année, et 0 facture erronée. Pas de données au-delà. La précédente tentative de réécriture avait échoué après 3 ans
Utiliser le processus de revue de code pour retenir en otage les changements jusqu’à ce qu’ils conviennent à une équipe avec beaucoup de changements et des évolutions permanentes, c’est un dysfonctionnement
Une politique de « mise à niveau au fil de l’eau » laisse une longue traîne de transitions à moitié terminées, ce qui rend l’adaptation des nouveaux développeurs à la codebase plus difficile. L’orientation produit ne garantit pas qu’on repasse régulièrement par toutes les parties de la codebase, donc la transition ne se termine jamais. Certaines zones du produit restent abandonnées pendant des années
Si le passage à la nouvelle politique est important, il faut le traiter comme un projet ciblé à part entière ; sinon, c’est que ce n’est pas important
Ils espèrent que des bombes à retardement de travail non planifié disséminées dans toute la codebase exploseront au hasard au détour de tâches sans rapport
Si la nouvelle norme est importante, il faut mettre le code à jour ; sinon, il ne faut pas le faire. Compter sur l’aléatoire pour retarder le travail urgent, ce n’est pas un plan
Lire cela comme un problème de revue de code est une erreur. Le problème, c’est que l’entreprise a fait passer un processus constitué de barrières internes avant les principes
Tout processus a besoin d’une issue de secours. S’il s’agit d’un changement visant à éviter un licenciement, alors toutes les issues de secours devraient être activées