- En 2016, l’organisation Business Intelligence d’Uber a créé un outil d’exécution de modèles R et une interface semblable à Excel pour utiliser rapidement les données nécessaires à la concurrence avec Uber China, mais la fonctionnalité a vite été supprimée après la vente d’Uber China à Didi
- R-Crusher était un système interne visant à remplacer le flux instable où les data scientists téléchargeaient des données Vertica sur leurs ordinateurs portables et faisaient tourner des modèles R toute la nuit par un outil d’exécution basé sur une API
- Les équipes des villes chinoises étaient habituées aux fichiers Excel pour calculer les incitations des chauffeurs ; plutôt que de transposer manuellement des centaines à des milliers de formules en JavaScript, l’équipe a implémenté un moteur de tableur capable d’exécuter des fichiers XLS et leurs formules dans le navigateur
- Si les résultats divergeaient subtilement d’Excel, c’était parce que les data scientists effectuaient une régression linéaire au moyen de références circulaires ; le comportement a été aligné sur celui d’Excel, en recalculant en boucle jusqu’à convergence
- Même du code bien conçu peut être supprimé si le problème business qu’il devait résoudre disparaît ; la valeur de l’ingénierie tient davantage à la résolution du problème qu’à la durée de vie du code
L’outil de données interne qui soutenait Uber China
- Après avoir rejoint Uber en 2016, j’ai travaillé dans l’équipe Crystal Ball comme premier ingénieur frontend
- L’équipe comptait environ quatre personnes, avec une forte dominante backend
- Mon rôle consistait à transformer des outils internes en interfaces que les employés de l’entreprise pouvaient réellement utiliser
- À l’époque, les data scientists téléchargeaient des données depuis Vertica et exécutaient des modèles R toute la nuit sur plusieurs ordinateurs portables
- Le matin, seuls les ordinateurs dont le modèle n’avait pas planté produisaient des données potentiellement utilisables dans la journée
- Les machines en échec ne produisaient pas les données nécessaires, ce qui conduisait l’entreprise à perdre de l’argent
- R-Crusher, que l’équipe construisait, ressemblait à un système de CI qui récupérait et exécutait du code via des appels API, puis générait des fichiers de résultats
- Wesley, le frontend de R-Crusher, a eu une première version prête quelques semaines après mon arrivée
- Les 6 à 7 mois suivants ont été consacrés à des fonctionnalités utilisateur, des outils de débogage et l’extension de l’équipe frontend
Le marché chinois et le calcul des incitations chauffeurs
- En 2016, les grands axes internes chez Uber étaient la réécriture/refonte de l’application et Uber China
- Le travail de l’équipe Crystal Ball visait finalement à soutenir Uber China
- R-Crusher était un outil destiné à obtenir les données nécessaires pour rivaliser avec Didi
- La Chine représentait une opportunité importante pour Uber, et une partie des données requises devait provenir de R-Crusher
- Une nouvelle demande est arrivée pendant l’été
- Un modèle générait pendant la nuit des données de prévision de la demande de courses en Chine
- Ces données n’étaient pas utiles seules ; insérées dans un onglet précis d’un tableur Excel, elles devenaient un outil interactif de calcul des incitations chauffeurs
- Le responsable financier a demandé que ce tableur soit intégré dans Wesley
- Les équipes des villes ne savaient utiliser qu’Excel et demandaient de « faire comme Excel »
- L’équipe a expliqué qu’elle manquait de temps d’ingénierie, mais la réponse a été qu’en l’absence de l’outil, l’entreprise perdait des millions de dollars chaque jour
Imiter Excel dans le navigateur
- Il n’y avait pas le temps de porter le tableur en code Python ou R côté backend, et il fallait donc écrire beaucoup de JavaScript côté frontend
- Un prototype précédemment créé chez Box, Box Sums, a servi de base
- Il comportait une interface de tableur simple en React et un moteur de formules basique
- Lorsqu’on déposait un fichier XLS/XLSX sur la page, une bibliothèque Node en analysait le contenu
- L’implémentation pour Uber ne visait pas à reproduire Excel lui-même, mais un comportement proche d’Excel
- Lire un fichier XLS en entrée
- Exécuter des formules Excel sur les données
- Le backend fournissait les données de demande de courses sous forme de tableau à deux dimensions, et le frontend les injectait dans le moteur de formules comme un onglet caché
- Toutes les cellules autres que celles que l’utilisateur devait manipuler étaient rendues en lecture seule
- Le point clé était de ne pas traduire directement en JavaScript les centaines à milliers de formules denses
- Pendant l’implémentation, les formules ont été extraites du fichier XLS, et les fonctions et syntaxes nécessaires ont été ajoutées au moteur de formules
-
Extension de la syntaxe Excel
- Références absolues de cellules
- Références de cellules dans d’autres feuilles
- Syntaxe de tableur absente de la démo Box existante
-
Des chiffres presque bons, mais faux, et des références circulaires
- Lors de la première comparaison, les résultats d’Excel et de notre propre moteur différaient très légèrement
- Quand Excel affichait
3.03, notre sortie était3.01 - Quand Excel affichait
1.002, notre sortie était1.000
- Quand Excel affichait
- Les valeurs presque correctes étaient plus délicates que des valeurs franchement fausses
- Il était plus probable qu’il s’agisse d’un écart subtil de calcul que d’une simple erreur de logique
- Les tests unitaires passaient, et la différence entre les
doubleJavaScript et la représentation en virgule flottante d’Excel n’était pas en cause - Après avoir interrogé un data scientist, la cause est apparue
- Le tableur utilisait des références circulaires pour effectuer une régression linéaire
- Excel ne traite pas toujours les références circulaires comme des erreurs
- Lorsque les valeurs calculées convergent avec un écart inférieur à un certain epsilon, il arrête les calculs itératifs et considère l’opération comme réussie
- L’implémentation a été modifiée pour détecter le graphe de dépendances circulaires et comparer l’écart entre l’ancienne et la nouvelle valeur calculée
- Si l’écart était suffisamment faible, la nouvelle valeur était utilisée
- Sinon, le nombre d’itérations augmentait et le calcul continuait
- Le seuil maximal d’itérations a été fixé à 1000
- La modification a pris environ un jour et demi, et la sortie a fini par correspondre à celle d’Excel
- Des tests ont été écrits et l’ensemble a été intégré à Wesley
- Le projet a été livré la deuxième semaine de juillet
Les exigences de sécurité après le lancement et l’abandon soudain
- L’outil a effectivement été lancé, et les membres des équipes des villes d’Uber China s’y sont connectés pour l’utiliser
- D’après ce que je sais, les chiffres générés ont servi aux incitations chauffeurs
- C’était la troisième semaine de juillet
- La dernière semaine de juillet, le responsable financier a signalé comme problème le fait qu’un clic sur une cellule affichait la formule
- La crainte transmise était que des employés de Didi postulent comme stagiaires chez Uber China pour exfiltrer des données
- Ce modèle de menace n’avait pas été partagé à l’avance avec l’équipe d’ingénierie
- Pour protéger complètement les formules, il aurait fallu déplacer les calculs côté serveur, mais cela sortait du périmètre demandé
- La correction immédiate a consisté à masquer les formules dans l’interface lors du clic sur une cellule
- La première semaine d’août 2016, Uber China a été vendu à Didi
- Beaucoup d’employés l’ont d’abord appris par des alertes d’actualité
- Quelques heures plus tard, un e-mail interne a annoncé la transaction
- Avec la disparition d’Uber China, cette interface a été retirée de Wesley
- C’était une interface sur mesure pour un traitement de données qui ne serait plus jamais exécuté
- Il n’y a pas eu d’autre demande pour recréer Excel dans le navigateur
Résoudre le problème plutôt que prolonger la vie du code
- Sur le moment, je n’ai pas ressenti de grande perte ni de forte déception
- J’ai d’abord pensé que j’aimerais publier le code sur GitHub, puis je suis passé à la tâche suivante
- Il restait une petite déception de voir un code travaillé être utilisé si brièvement puis disparaître
- Le code qu’écrit un ingénieur devient un jour du code legacy
- Quelqu’un pourra un jour prendre plaisir à le supprimer
- Même du code bien conçu n’a pas pour objectif en soi d’être maintenu longtemps
- Grandir en tant qu’ingénieur, c’est se rapprocher d’une meilleure création de valeur business grâce à la technologie
- Cette valeur peut être créée de plusieurs manières : livrables techniques, collaboration, mentorat, soutien à l’équipe, etc.
- Après la disparition d’Uber China, il ne restait plus de valeur business supplémentaire à créer avec ce projet
- Continuer à pousser le sujet n’aurait aidé ni les individus ni l’entreprise
- L’expression DevOps « Cattle, not pets » s’applique aussi au code
- Le code est un moyen d’accomplir un travail ; si ce travail n’est plus utile, il doit être prêt à être mis à la retraite
- Traiter le code comme un animal de compagnie par attachement émotionnel va à l’encontre de la compréhension du business
Les questions que laisse un projet abandonné
- Le fait qu’un projet soit supprimé ne signifie pas nécessairement qu’il a échoué
- Un travail abandonné laisse les questions suivantes
- Avons-nous construit quelque chose qui ne respectait pas les contraintes du projet ?
- Avons-nous construit ce qui était demandé, mais la demande était-elle mauvaise dès le départ ?
- Le problème central a-t-il été mal compris ?
- La solution demandée répondait-elle aux besoins réels des utilisateurs finaux ?
- Y avait-il des questions que nous n’avons pas posées aux parties prenantes ?
- Les attentes étaient-elles inexactes ou ambiguës ?
- Le niveau de robustesse livré était-il nécessaire ?
- Une solution plus simple ou moins ingénieuse aurait-elle suffi ?
- Avons-nous mal défini les critères de réussite ?
- Existait-il un critère de réussite autre que « construire ce qui a été demandé » ?
- Voir la fin d’un projet uniquement comme un échec fait perdre l’occasion d’apprendre où les problèmes non techniques ont déraillé
- Même une pièce conçue avec soin peut être supprimée si elle ne fonctionne pas harmonieusement dans un système plus vaste
1 commentaires
Avis de Hacker News
La meilleure citation, c’était celle-ci : « Des gens qui travaillent chez Didi postulent comme stagiaires chez Uber China, puis exfiltrent nos données. On ne peut pas les laisser voir les formules. Sinon, ils copieront exactement ce qu’on fait ! »
C’est vraiment juste. Les Américains ne mesurent pas le niveau d’espionnage économique et industriel qui se produit chaque jour en Chine. Vers le milieu des années 2000, en intervenant sur un incident de compromission distinct dans une entreprise tech que je ne peux pas nommer, on m’a dit : « Nous avons ouvert un centre technologique au Xinjiang, et ces derniers temps il y a un nombre inhabituellement élevé de badges d’accès perdus. » Quand j’ai demandé : « Vous avez envisagé qu’ils n’aient peut-être pas été perdus, mais vendus contre de l’argent ? », un silence a suivi.
Je ne sais pas si les dirigeants le savent et s’en moquent, ou s’ils sont simplement incompétents, mais la Chine a industrialisé à grande échelle l’espionnage industriel. Plus récemment, GE Aviation en a aussi été victime : https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
Ensuite, ils montent une société en Chine, lèvent des fonds auprès d’investisseurs chinois et fabriquent un produit quasiment identique pour le marché chinois. On peut citer par exemple Thoratec/Abbot Heartmate III et CH Biomedical, ou encore Auris/Verb/J&J Robotic & Digital Solutions et Renovo Surgical.
Ironie du sort, certaines de ces entreprises, une fois qu’elles ont réussi en Chine, cherchent ensuite à vendre aux États-Unis et en Europe et à y concurrencer les acteurs en place. Ce n’est même plus un secret ni une magouille en coulisses : dans notre secteur, cela se fait au grand jour et c’est globalement accepté comme « comme ça ».
Autre point : il est très difficile pour une entreprise étrangère opérant en Chine de protéger ses actifs. C’est pourquoi les entreprises avisées n’essaient même pas de le faire directement et concèdent souvent des licences à des entreprises chinoises pour le marché chinois. C’est au moins une façon d’avoir une chance que tout ne soit pas volé.
Dans une agence où je travaillais autrefois, nous avions fait venir un designer industriel pour créer un joli boîtier destiné à du matériel iBeacon. Le résultat était excellent.
Nous avons confié le moulage par injection à une entreprise chinoise, et les échantillons étaient plutôt bons, donc nous avons décidé de les utiliser. Quelques semaines plus tard, nous avons vu notre boîtier en vente sur Alibaba/AliExpress.
Cela ne veut pas dire que l’Occident ou d’autres pays sont parfaits, mais ce n’est pas le sujet ici. Toutes les personnes que je connais qui ont travaillé avec l’industrie manufacturière ou les affaires en Chine ont connu des situations du type « ils ont copié », « ils ont vendu nos efforts à quelqu’un d’autre », « ils ont fourni une qualité de x inférieure à celle convenue ».
Les contre-arguments finissent toujours par être « l’Occident fait aussi X » ou « c’est raciste ».
Les entreprises chinoises, surtout celles qui vendent sur Ali-X, adorent vraiment ce système. Elles peuvent s’approprier gratuitement la propriété intellectuelle et évincer le fabricant d’origine par les prix. Les conceptions de makers publiées sur Tindie et ailleurs sont souvent copiées et réapparaissent sur Ali.
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
En lisant ce texte, je m’attendais à une histoire où du code personnalisé complexe était retiré puis supprimé, mais contrairement à mes attentes, l’auteur a grandi en tant qu’ingénieur.
L’adage DevOps « Cattle, not pets » s’applique parfaitement ici. Le code et les produits créés avec ce code ne sont pas des animaux de compagnie, mais du bétail. Ils font un travail, et lorsque ce travail n’est plus utile, ils doivent être prêts à prendre leur retraite. Traiter le code comme un animal de compagnie pour des raisons sentimentales, c’est agir en opposition directe aux intérêts de l’entreprise.
Beaucoup de code est amusant à écrire, et beaucoup de problèmes sont amusants à résoudre. Mais une entreprise, surtout une startup, doit être extrêmement concentrée. Ma carrière consiste en fait surtout à m’asseoir dans des salles de réunion pour dire à de jeunes ingénieurs passionnés de ne pas construire. C’est un peu déprimant, mais c’est aussi indispensable.
Un bon ingénieur peut résoudre n’importe quel problème avec du code ingénieux. Un excellent ingénieur comprend que certains problèmes n’en sont pas vraiment, et qu’un lien de téléchargement XLS mis à jour chaque jour aurait peut-être suffi.
Je travaillais sur un système de supervision pour un service hébergé en interne, et mon responsable voulait acheter un petit utilitaire qui surveillait un détail mineur de notre environnement. J’étais un peu vexé qu’on envisage de payer pour quelque chose que je pouvais construire moi-même.
Mon responsable m’a demandé : « Combien de temps te faudrait-il pour l’écrire et le tester ? » J’ai répondu : « Probablement une semaine, peut-être un peu plus si quelque chose s’avère délicat. » Il a alors demandé : « Cet outil coûte 500 dollars. Combien valent 40 heures de ton salaire horaire ? »
J’ai eu un déclic à ce moment-là, et depuis je n’ai plus jamais construit en interne quelque chose que l’entreprise pouvait acheter moins cher.
La checklist au bas de la page Substack ne suffit pas non plus pour ce niveau de compréhension des exigences. Ces questions ne font que décrire la situation, et les poser n’aurait pas permis d’arriver à cette solution simple. Penser en checklist est une béquille, et cela rend les problèmes inutilement complexes.
Ici, les signaux importants étaient tous organisationnels et sociaux ; ce n’était pas un problème qu’on pouvait résoudre en améliorant le processus. Quelqu’un qui ne participe pas aux détails d’implémentation ne peut pas répondre à des questions sur les détails d’implémentation.
« Faites juste un truc comme Excel » est une réponse de mauvaise qualité venant de quelqu’un qui a des objectifs complètement différents. Il aurait fallu discuter avec des personnes plus proches des utilisateurs réels et construire les objections à partir de là. Ce qui manquait, c’était la capacité à repérer des hypothèses faibles, et le courage de s’abstenir délibérément d’écrire du code tant que les détails n’étaient pas assez figés pour que toutes les parties soient d’accord. Il ne faut pas simplement dire oui à la « personne responsable ».
En 2006 déjà, j’ai eu une longue conversation pour convaincre quelqu’un de ne pas s’engager dans cette voie, et en 2026, quelqu’un voudra encore le faire.
La capacité à s’arrêter et à se demander « comment d’autres ont-ils résolu exactement ce problème ? » est une part très importante de la progression en tant que développeur ; j’aimerais que l’école y consacre davantage d’attention.
Le simple fait qu’il explique l’avoir terminé avec succès et dans les délais ne permet pas de conclure que les choix d’implémentation étaient mauvais. Au contraire, le projet a eu tellement de succès qu’il a fini par implémenter trop de fonctionnalités d’Excel, puis il a corrigé le problème en les retirant. Comment aurait-on pu retirer cela avec un lien de téléchargement XLS ?
Le point essentiel est de ne pas trop s’attacher à son code ; dans certains cas, cela peut vouloir dire « ne le construisez pas vous-même, utilisez un lien de téléchargement XLS », mais ce n’est pas toute l’histoire.
Les passages « Rien ne s’était passé, mais j’ai gardé ce code de côté pour le jour où il servirait. Mon idée était de l’adapter aux besoins d’Uber » et « Ma première réaction a été de publier le code sur GitHub » sont très surprenants.
Ce code n’est-il pas la propriété de Box ou d’Uber ? L’auteur ne mentionne pas avoir demandé l’autorisation avant de le publier sous licence MIT.
Si Uber veut du code JavaScript de plusieurs milliers de lignes qui ne vient même pas d’eux, qui date de plus de six mois et qui a été utilisé moins d’un mois, ils peuvent m’envoyer une lettre.
Le passage « il n’arrivait tout simplement pas à croire que j’avais écrit tout un moteur de tableur fonctionnant dans le navigateur » est difficile à croire pour moi aussi, et pas dans le bon sens
Avec Apache POI, on peut faire tourner Excel en headless. En Java, on peut récupérer des feuilles et interagir avec elles par programmation ; je l’ai utilisé dans un précédent poste exactement pour la même raison. Fonctions, références de cellules, etc., tout fonctionnait très bien
Il a juste eu de la chance en trouvant le problème de « circ ». Que fera-t-il avec toutes les petites particularités cachées d’Excel qu’il rencontrera ensuite ? Va-t-il vraiment créer et maintenir une réplique complète d’Excel en JS ? Est-ce vraiment l’objectif de l’équipe frontend ?
Avec une petite recherche, il me semble qu’on aurait pu éviter ici plus de 90 % du travail. Et en prime, l’équipe backend aurait pu s’en charger
Uber exploitait ses propres datacenters. Obtenir une machine Windows ou une VM pour faire tourner le vrai Excel aurait probablement relevé du miracle. Je pouvais lancer un nouveau service frontend en une trentaine de minutes, et il y avait déjà du code qui tournait dans une certaine mesure, donc je ne partais pas totalement de zéro. Il faut aussi tenir compte du fait que ce système devait être utilisé simultanément par plusieurs personnes avec des jeux de données différents
S’ils avaient continué à demander davantage de fonctionnalités et une équivalence avec Excel, nous l’aurions réévalué, mais ce n’est pas ce qui s’est passé
Je ne m’attends pas à ce que beaucoup de gens fassent le même choix que moi. Mais ça a marché, et étonnamment bien. Si tout ce que vous avez retenu de l’article est « c’était un gros projet complexe », alors l’article n’a pas correctement transmis le message que je voulais faire passer
À sa place, j’aurais probablement davantage questionné la spécification de l’UI et plaidé pour faire tourner Excel côté backend. Mais quand il y a des saisies numériques un peu partout, c’est effectivement une UI familière
J’ai toujours trouvé amusant cet article sur la création d’un tableur en 100 lignes de F# : https://tomasp.net/blog/2018/write-your-own-excel/ L’étendre à l’ensemble de fonctionnalités nécessaire ici reste gérable
Au final, il a créé une réplique maison d’« Excel » comme UI du modèle, au motif que « les équipes des villes ne savent utiliser qu’Excel »
J’aurais fait l’inverse. J’aurais connecté Excel aux données exportées par le modèle pour permettre aux équipes des villes de continuer à utiliser le vrai Excel. Il me semble que c’est ce que font la plupart des équipes financières
Pour les curieux, la documentation sur les références circulaires dans Excel : https://support.microsoft.com/en-us/office/remove-or-allow-a...
Si vous n’êtes pas familier avec les calculs itératifs, il y a de fortes chances que vous ne vouliez pas laisser des références circulaires telles quelles. Vous pouvez activer le calcul itératif, mais vous devez décider combien de fois les formules seront recalculées. Si vous activez le calcul itératif sans modifier le nombre maximal d’itérations ni la variation maximale, Excel arrête le calcul après 100 itérations ou dès que toutes les variations de valeurs de la référence circulaire deviennent inférieures à 0,001 entre deux itérations, selon ce qui arrive en premier. Cela dit, vous pouvez contrôler le nombre maximal d’itérations et la variation acceptable
Je me demande si l’auteur aurait vu la situation différemment si Uber ou Box avaient revendiqué ce code comme le leur. Même si le code n’a pas réalisé son potentiel réel, le fait qu’au moins le monde entier puisse le voir et le reconnaître doit apporter une certaine catharsis.
Quand j’étais stagiaire, j’ai créé un langage de programmation complet. Il utilisait l’évaluation paresseuse et le garbage collection, avec aussi des bizarreries propres à l’application, comme le fait que des adresses MAC sans guillemets soient une syntaxe valide.
Il n’y avait rien comme du bytecode ou un JIT : l’interpréteur parcourait l’arbre syntaxique et empilait/dépilait des valeurs sur une pile, mais c’était assez rapide pour ce que nous faisions. L’interpréteur était écrit en ANSI C pur, et Valgrind en était très satisfait.
Il est peut-être totalement oublié, ou il est peut-être devenu central dans l’infrastructure technique de cette entreprise. Ce code n’est jamais sorti du labo isolé que j’avais mis en place, donc je n’ai aucun moyen de le savoir. Il y a trois ans, tout juste sorti de l’université, c’était de loin le « logiciel réellement utile » le plus cool que j’aie écrit, et il reste encore dans le haut du panier. Je me demande parfois ce qu’il est devenu.
L’auteur semble penser que le fait d’avoir demandé à un manager intermédiaire, voire à un cadre dirigeant, « vous le voulez ? », et que celui-ci ait répondu « non », engage juridiquement l’entreprise.
La phrase « Il est facile de traiter un code particulièrement ingénieux ou élégant comme un chef-d’œuvre. En réalité, c’est peut-être un bel objet décoratif. Mais nous, ingénieurs, ne sommes pas dans le métier de fabriquer de beaux objets décoratifs : nous sommes dans celui de produire des résultats » m’a parlé.
Cela dit, comme toute personne ayant vu mon code le sait, j’aime que mon code et ce qu’il fait soient aussi très beaux. En général, j’écris du code que je vais maintenir, donc il faut que je puisse encore le comprendre un an plus tard.
Je suis actuellement dans la dernière ligne droite d’un projet que je ne présenterai pas ici, et pour lequel je n’ai pas l’intention de m’attribuer beaucoup de mérite, mais c’est vraiment quelque chose d’excellent. La raison pour laquelle c’est devenu ainsi, c’est que personne ne paie pour cela, et que personne ne gagne d’argent avec.
L’argent peut tout gâcher, tout en rendant tout possible.
C’est un vraiment excellent article écrit du point de vue de l’ancienne équipe BI d’Uber. J’étais dans l’équipe Vertica à cette époque, et la quantité d’efforts consacrée aux incitations donnait le vertige. Les interruptions de service, les fonctionnalités produit et la bande passante d’ingénierie qui faisaient perdre plusieurs millions de dollars par jour étaient des sujets fréquents.
En particulier à l’époque d’Uber China, il aurait été très naturel qu’un directeur demande précisément un tableur comme UI. Personnellement, je chargeais aussi dans Vertica les prix FX depuis une feuille de calcul envoyée chaque mois par e-mail à l’équipe. Nous n’avions pas la bande passante pour inverser le flux de contrôle avec une collecte automatique, donc ce processus est resté en place plus d’un an.
La phrase « Même aujourd’hui, je n’ai jamais rien vu d’aussi bien conçu que le système d’applications internes d’Uber. Il fallait moins de 30 minutes pour passer de zéro à un Hello World exécuté avec une CI/CD complète sur un sous-domaine *.uberinternal.com » m’a un peu réchauffé le cœur.
À l’époque, chez Uber, j’avais participé à tout cela.