Amazon dit avoir fait passer des dizaines de milliers de ses propres applications Java de production de Java 8 ou 11 à Java 17 avec un agent, et estime l'équivalent manuel à plus de 4 500 années de travail de développement

Date de l'événement / signalement

Stade de la preuve

Tâches concernées

Où ceci s'applique

L'estimation interne d'Amazon sur l'ingénierie d'Amazon, publiée par l'entreprise qui vend l'outil — la partie qui fait le travail, celle qui le mesure et celle qui le vend sont la même, ce qui est dit ici parce que cela ne peut pas être vérifié de l'extérieur. L'entreprise publie aussi sa méthode : le temps économisé a été estimé à partir du nombre de dépendances Java migrées, en supposant un jour ou plus de temps de développeur par dépendance à la main. Notez ce qu'est la migration : une montée de version de langage a un compilateur et une suite de tests existante pour oracle, donc la réussite est vérifiable par machine à chaque étape — la forme la plus favorable possible pour ce genre d'automatisation, et non un résultat général sur le travail côté serveur. Et notez ce qui est affirmé et ce qui ne l'est pas : 4 500 années sont du travail non fait, par plus d'un millier de développeurs, sans aucune déclaration que l'un d'eux soit parti ou qu'un poste ait été supprimé.

Ce que cela veut dire

Ce que cela ne montre pas encore

Amazon a mesuré son propre travail avec son propre outil et publié son propre contrefactuel ; personne d'extérieur n'a vérifié l'hypothèse d'un jour par dépendance sur laquelle tout le chiffre repose. Rien là-dedans n'établit un changement d'effectifs — l'affirmation porte sur des heures non passées par des développeurs qui faisaient autre chose à la place. Et la propriété qui a fait fonctionner cela ne se transpose pas : écrire un nouveau point d'entrée, décider d'une frontière de cloisonnement ou choisir quoi dégrader à trois heures du matin n'ont aucun compilateur pour dire non.

Ce que vous pouvez vérifier

Cela change-t-il l'évaluation ?

Source