Temps de création des documents (DAT)
Le développement de logiciels est le fondement de l’innovation moderne. Pourtant, de nombreuses entreprises mesurent encore leur productivité à l’aide de paramètres dépassés, tels que les lignes de code, le nombre de validations ou le nombre d’heures passées à coder. Ces mesures ne vous apprennent rien d’utile. C’est pourquoi chez Metails se concentrent sur le temps de création de documents (Diff Authoring Time – DAT), une mesure qui reflète réellement la rapidité avec laquelle les ingénieurs peuvent créer, affiner et valider des modifications de code significatives.
Un « diff » n’est qu’une modification du code, c’est-à-dire la plus petite unité de l’évolution d’un logiciel. DAT suit le temps qu’il faut entre l’écriture, les tests et le débogage avant que cette modification ne soit validée. Contrairement aux mesures superficielles qui peuvent être manipulées, DAT est basé sur des données. Il tire des informations en temps réel des environnements de développement intégré (IDE), des systèmes de contrôle des versions et même du suivi au niveau du système d’exploitation afin de comprendre où les développeurs s’enlisent.
Pourquoi cela est-il important ? Parce que la vitesse est importante. Les goulets d’étranglement tuent l’élan, et le DAT permet d’identifier les frictions dans le système. Le DAT moyen chez Meta ? 50 minutes pour 87 % des différences. Cela donne un aperçu de la façon dont les ingénieurs travaillent à grande échelle, en veillant à ce que l’entreprise construise et déploie efficacement.
Optimiser l’expérience des développeurs (DevEx) grâce à DAT
Les ingénieurs en logiciel résolvent les problèmes. Chaque minute passée à se débattre avec des outils inefficaces est une minute qui n’est pas consacrée à l’innovation. Meta utilise le DAT pour identifier ces inefficacités et apporter des améliorations ciblées.
Investissez dans des outils. Si un processus ralentit les développeurs, ils testent d’autres solutions. Les tests A/B, largement utilisés dans le développement de produits, sont appliqués en interne aux outils de développement. Un test récent a porté sur le langage de programmation Hack de Meta (une version optimisée de PHP). Les ingénieurs ont constaté que l’exécution de vérifications de type plus tôt dans le processus de codage réduisait les perturbations et diminuait la DAT de 14 %. Il s’agit d’un gain considérable pour quelque chose d’aussi simple qu’une modification lorsqu’un contrôle automatisé s’exécute.
Ce qu’il faut en retenir ? Les petits points de friction, répétés des milliers de fois au sein d’une équipe d’ingénieurs, s’ajoutent aux pertes de productivité massives. Le DAT permet d’éliminer le bruit et de se concentrer sur la résolution des problèmes les plus importants.
Faire évoluer la définition du DAT sans la briser
Les indicateurs ne sont utiles que s’ils restent cohérents. Si vous les modifiez trop, vous perdez la possibilité de les comparer. S’ils restent statiques, ils deviennent obsolètes. Meta en est maintenant à sa cinquième itération du DAT, affinant la façon dont il est mesuré sans perturber sa définition de base.
La cohérence est essentielle. Si des équipes différentes mesurent la productivité différemment, les comparaisons n’ont plus de sens. La prochaine étape de Meta consiste à normaliser la façon dont le DAT est mesuré dans tous les groupes d’ingénieurs, en veillant à ce que chaque différence soit suivie de la même façon.
Mais voici le défi : la mesure doit évoluer. Le développement de logiciels n’est pas statique, les outils, les processus et les meilleures pratiques changent. Moritz Beller, chercheur en génie logiciel chez Meta, résume bien la situation : « Vous ne voulez pas que la définition de votre mesure change, mais vous voulez aussi que la mesure évolue. Il s’agit de précision sans rigidité, ce que toutes les entreprises à forte croissance et axées sur l’ingénierie devraient prendre en considération.
Pourquoi Meta n’utilise pas le DAT pour évaluer les développeurs individuels ?
Vous vous demandez peut-être : pourquoi ne pas utiliser la DAT pour évaluer les développeurs individuels ? Cela n’améliorerait-il pas les performances ?
La réponse est simple : cela se retourne contre vous.
Meta comprend que le suivi individuel peut nuire au moral et tuer la créativité. L’ingénierie logicielle n’est pas seulement une question de rapidité, c’est aussi une question de résolution de problèmes. Si les développeurs ont l’impression d’être constamment surveillés, ils commencent à optimiser leur travail en fonction de la mesure plutôt que de la mission. C’est pourquoi le TAD n’est mesuré qu’au niveau de l’organisation.
Sarita Mohanty, data scientist chez Meta, reconnaît que le DAT n’est de toute façon pas toujours précis à 100 % au niveau individuel. Le vrai danger ? La sécurité psychologique. Meta a réduit ses effectifs de 23 % au cours des trois dernières années, et une autre réduction de 5 % est à venir. Dans un tel environnement, le suivi du TAD individuel pourrait créer une anxiété inutile, réduisant la productivité au lieu de l’améliorer.
« Le DAT est utilisé comme une mesure de haut niveau, un moyen de voir les grandes tendances et de s’assurer que l’ensemble de l’organisation d’ingénierie progresse plus rapidement, et pas seulement une poignée de personnes.
BlueOptima vs. Meta
Meta n’est pas la seule entreprise à mesurer les performances des développeurs, mais son approche est différente de celle de certains outils de suivi plus agressifs.
Prenez BlueOptima, un outil d’évaluation comparative d’entreprise qui regroupe les données de développement, y compris les heures de codage et les mesures de productivité individuelle. Contrairement à Meta, BlueOptima permet un suivi au niveau individuel, mais avec un accès limité aux responsables. L’idée ? Les chefs d’équipe peuvent utiliser les données pour améliorer les flux de travail sans pénaliser les développeurs.
Adam Minter, directeur de clientèle chez BlueOptima, l’explique ainsi : « Vous n’embauchez pas de mauvais développeurs. Si quelque chose se passe, vous devez l’identifier et les aider. Nous essayons de rendre ce pouvoir aux développeurs ».
Il s’agit d’une philosophie différente. Meta évite le suivi individuel pour préserver la dynamique de l’équipe, tandis que BlueOptima considère la transparence comme un moyen de responsabiliser les développeurs et d’optimiser les équipes. Quelle est l’approche la plus efficace ? Cela dépend de la culture de l’entreprise, mais une chose est sûre, de mauvaises mesures pour les développeurs font plus de mal que de bien.
L’avenir de la productivité des développeurs
La vitesse et l’efficacité sont importantes. Mais l’ingénierie n’est pas une question de mesures, c’est une question de personnes.
La productivité des développeurs ne consiste pas seulement à écrire du code rapidement, mais aussi à résoudre des problèmes de manière créative. C’est pourquoi des indicateurs comme le DAT doivent être complétés par des données qualitatives. Si vous vous concentrez uniquement sur les chiffres, vous risquez d’optimiser la vitesse au détriment de l’innovation.
Henri Verroken, data scientist chez Meta, l’exprime le mieux : « L’enchantement des développeurs ne consiste pas simplement à examiner des données et à dire « nous savons mieux que quiconque ce que veulent les développeurs ». Il faut écouter les développeurs pour s’assurer qu’ils vivent une expérience agréable. »
Il s’agit là d’un point essentiel à retenir : utiliser les données pour éclairer les décisions, et non pour les imposer. Les meilleures équipes d’ingénieurs ne se contentent pas d’agir rapidement, elles agissent intelligemment. Et les meilleures entreprises ne suivent pas les développeurs, elles les soutiennent.
Dernières réflexions
Mesurer la productivité d’un logiciel ne consiste pas à compter les lignes de code. Il s’agit d’éliminer les frictions, d’investir dans les bons outils et d’optimiser l’efficacité à long terme.
Le DAT est un indicateur puissant, mais comme tous les indicateurs, il n’est qu’une pièce du puzzle. Le véritable objectif ? Permettre aux développeurs de faire leur meilleur travail.
Avancez rapidement. Optimisez judicieusement. Innovez sans relâche.
Principaux enseignements
- Des mesures améliorées pour les développeurs : Le Diff Authoring Time (DAT) de Meta fournit une mesure basée sur des données du temps écoulé entre la création du code et la validation, aidant les responsables à identifier les goulots d’étranglement et à améliorer l’efficacité globale de l’ingénierie.
- Investissements ciblés dans les outils : Les données DAT permettent d’effectuer des tests A/B pour l’optimisation des outils, tels que les premières mises en œuvre des contrôles de type qui ont montré une amélioration de 14 % des temps de cycle, ce qui permet d’orienter les investissements de manière plus intelligente.
- Des mesures évolutives mais cohérentes : Meta améliore continuellement DAT pour s’adapter à l’évolution des pratiques de développement tout en maintenant la cohérence entre les équipes. Les décideurs devraient privilégier les mesures adaptables qui restent comparables dans le temps.
- Favoriser la sécurité psychologique : En évitant le suivi des performances individuelles avec le DAT, Meta protège le moral et la créativité de l’équipe. Les dirigeants devraient se concentrer sur des mesures à l’échelle de l’organisation qui soutiennent une culture de collaboration et d’innovation.
