Qu’est-ce qui rend les développeurs productifs ?

• De nombreux facteurs influencent la productivité des développeurs
• Certains sont clairs et faciles à mesurer, mais d’autres sont difficiles à mesurer et ont donc tendance à être négligés

Savoir quoi construire (Knowing what to build)

• Construire rapidement la mauvaise chose n’est absolument pas productif
  • il faut savoir ce que veulent les clients,
  • savoir ce que les autres équipes peuvent accepter (combien d’index peuvent être ajoutés à une table de base de données, si des informations légalement non autorisées peuvent être partagées ?),
  • et savoir ce qui a déjà été essayé sans fonctionner

Faire moins de travail

• Finir le travail rapidement, c’est bien, mais c’est encore mieux si l’on peut carrément ne pas avoir à le faire
• Les processus de l’entreprise peuvent ajouter du « travail occupationnel » qui réduit la productivité
  • il existe parfois des moyens simples d’ajuster le processus pour fournir la même valeur avec beaucoup moins de travail
• Un certain niveau d’effort peut être nécessaire pour « garder les lumières allumées » (Keep the lights on, KTLO)
• Il s’agit de tâches à effectuer en continu (par ex. répondre aux tickets de support), mais qui ne font pas avancer un projet
• Ces tâches peuvent sembler productives selon plusieurs métriques (nombre de tickets clôturés, nombre de commits fusionnés), mais elles ne rendent pas l’entreprise meilleure

Des outils réactifs

• Les développeurs utilisent des outils en permanence : éditeur, git, système de build
• Le temps ajouté par ces outils représente un coût important selon leur fréquence d’utilisation
• Ce n’est pas seulement un coût horaire : cela casse aussi la concentration du développeur

Les connaissances dans la tête des développeurs

• C’est difficile à mesurer
• Toutes choses égales par ailleurs, un développeur qui possède beaucoup de connaissances pertinentes est plus productif
  • parce qu’il sait comment le code fonctionne et n’a donc pas besoin de l’examiner en profondeur,
  • il sait utiliser les outils et connaît les pièges à éviter
  • il pose les bonnes questions
  • les développeurs 10x existent, et ce sont des « personnes qui connaissent très bien la base de code »
• Cela signifie qu’une équipe ne devrait pas posséder plus d’éléments qu’elle ne peut collectivement garder en tête. (Idéalement, le bus factor est supérieur à 1.)
  • cela signifie aussi qu’il est avantageux de minimiser la fréquence des changements d’ownership
  • personne n’en saura plus que la personne qui l’a construit
  • idéalement, les personnes qui utilisent un système pour la première fois devraient travailler avec celles qui le connaissent déjà et apprendre à leurs côtés
• Il faut des frontières claires entre les systèmes
  • une interface propre avec une sémantique simple permet de réfléchir aux propriétés de l’interface sans avoir besoin de connaître tout le système qui se trouve derrière
• La documentation est un bon moyen de transmettre la connaissance
  • c’est particulièrement important lorsqu’un développeur doit effectuer une tâche spécifique qu’il ne connaît pas bien
  • si la documentation manque, le développeur devra chercher lui-même comment faire, commettre des erreurs et refaire le travail, ou attendre qu’une autre équipe réponde à ses questions, ce qui peut ralentir fortement l’exécution
  • cela peut très vite transformer une tâche d’une heure en tâche de deux jours
  • si 100 développeurs doivent faire cette tâche, le coût d’une seule page de documentation manquante peut correspondre au salaire annuel d’un développeur
• Cela signifie aussi qu’il faut davantage de spécialisation (Specialization)
  • exiger de tous les développeurs qu’ils réalisent un large éventail de tâches est contre-productif
  • une heure passée dans un processus lié à certains systèmes de sécurité ou à la planification de capacité n’est pas la même chose qu’une heure passée à comprendre le domaine pour résoudre un problème

Une infrastructure utile

• L’infrastructure doit aider, pas faire obstacle
• Elle doit être raisonnablement bien alignée avec l’ensemble des tâches à accomplir
• Chaque composant de l’infrastructure est conçu avec des cas d’usage spécifiques en tête, mais dans les projets, on sort parfois de ces cas d’usage
  • dans ces moments-là, entendre « vous devez utiliser uniquement notre infrastructure » ou « notre infrastructure ne permet pas ce genre de chose » est frustrant
  • cela oblige soit à contourner l’infrastructure, soit à perdre du temps en réunion pour convaincre les propriétaires de l’infrastructure d’accepter les exigences

Peu de dette technique

• Le code existant n’est jamais parfaitement adapté à ce que vous voulez faire
  • l’auteur initial du code n’avait pas de « boule de cristal » pour voir quels changements vous alliez faire
  • mais certains codes sont bien plus faciles à modifier que d’autres
• La réponse à « comment peut-on faire X ? » ne devrait pas être « il faut tout reconcevoir »
• S’il y a beaucoup de dette technique, même un petit changement fonctionnel oblige à modifier plus largement le système
• Réduire la dette technique permet de minimiser la surface qu’il faut (a) comprendre et (b) modifier
• Les projets destinés à rembourser la dette technique doivent être menés à terme
  • si on les abandonne en cours de route ou qu’on baisse leur priorité, le système peut devenir pire qu’au départ

Un faible taux d’échec

• Quand il y a des échecs d’exécution d’outils, des échecs de build, des échecs de déploiement ou des régressions dues à des erreurs en production, c’est du temps perdu
• Réduire la probabilité de ces échecs améliore la productivité
• Au-delà de l’ingénieur qui subit l’échec, cela tend aussi à faire perdre du temps à l’équipe propriétaire du système en échec (parce qu’il faut analyser et corriger le problème ensemble)

Les pratiques productives sont pratiques (Productive practices are practical)

• La meilleure façon d’apprendre à résoudre un problème précis est d’écrire un prototype
• Si l’environnement gêne le prototypage, même l’approche la plus productive peut être empêchée
• S’il est difficile d’utiliser les outils de monitoring, les développeurs créeront moins de dashboards, mesureront moins de choses et les décisions seront moins guidées par les données
• À l’inverse, si l’on découpe de gros changements en petites revues de code, il devient plus facile de les relire et de les déployer

La capacité de concentration des ingénieurs

• Les ingénieurs travaillent selon un calendrier de production et doivent pouvoir se concentrer
• Cette concentration peut être volée par les réunions et les interruptions
• Parmi les interruptions figurent aussi les commandes CLI lentes, les tests lents, et les tâches pour lesquelles il faut faire des recherches parce qu’on ne sait pas comment s’y prendre
• Réfléchir à trop de sujets en une seule semaine nuit aussi à la capacité de concentration
• Les deadlines qui approchent, ou les questions restées sans réponse de la part d’un manager, occupent aussi de la RAM mentale quand on essaie de se concentrer sur autre chose

Finir le travail

• Construire 50 % n’est pas 50 % de productivité, mais 0 %
• Rien n’est moins productif qu’un travail qui sera jeté
• Il peut arriver qu’abandonner un projet en cours soit la bonne décision
  • lutter contre le biais des coûts irrécupérables est parfois la bonne chose à faire
  • mais il ne devrait pas y avoir de schéma récurrent où les priorités changent avant qu’un projet soit terminé
  • dans ce cas, la productivité de l’équipe peut tomber à 0

Conclusion

• On ne peut pas toujours construire des dashboards pour mesurer tous ces facteurs, mais on peut comprendre l’impact de ce genre de choses sur la productivité
• Résoudre ces problèmes peut augmenter fortement la quantité de travail réellement accomplie
• Certains problèmes sont étonnamment faciles à corriger
  • consacrer quelques heures à écrire de la documentation peut faire économiser des milliers d’heures à l’entreprise
• Quand il faut couper un arbre vite, il faut commencer par affûter la lame de la scie

[kofmania]

C’est un article avec beaucoup de passages qui se referment sur eux-mêmes.

[laeyoung]

« Quand la documentation manque, les développeurs doivent chercher eux-mêmes comment effectuer le travail, peuvent faire des erreurs et devoir refaire la tâche, ou attendre qu’une autre équipe réponde à leurs questions, ce qui peut ralentir leur rythme de travail. »

Ce n’est pas de la documentation de développement, mais quand on demande aux personnes qui viennent d’être onboardées de mettre à jour la documentation d’onboarding une semaine plus tard, elle s’améliore vraiment. Quand on arrive dans l’entreprise sans aucune information, ce sont elles qui savent le mieux, à ce moment-là, ce dont on a besoin.

Je me dis aussi que si les Readme.md des projets open source sur GitHub sont souvent relativement bien rédigés, c’est peut-être parce que beaucoup de premiers utilisateurs arrivent et donnent leur feedback.

[devsepnine]

Ces derniers temps, j’ai tellement de choses qui s’accumulent que je suis complètement débordé(e) T_T

[ahwjdekf]

L’infrastructure devrait être une aide, pas un obstacle —> à l’heure actuelle, en Corée, les entreprises sont loin d’en être là, en prenant la sécurité comme prétexte.

[hero512]

Je comprends le sentiment, mais cet article a été écrit en anglais. La situation semble similaire dans les entreprises anglophones aussi.

[kuroneko]

On dirait que c’est plus qu’un résumé, au niveau d’une vraie traduction... Merci pour ce récapitulatif détaillé.