Creé Excel para Uber, pero pronto lo desecharon
(basta.substack.com)- En 2016, la organización de Business Intelligence de Uber creó una herramienta para ejecutar modelos en R y una UI similar a Excel para usar rápidamente los datos necesarios en la competencia de Uber China, pero la función se eliminó poco después cuando Uber China fue vendida a Didi.
- R-Crusher era un sistema interno que buscaba reemplazar el flujo inestable en el que los data scientists descargaban datos de Vertica en laptops y ejecutaban modelos en R durante toda la noche por una herramienta de ejecución basada en API.
- Los equipos de ciudades en China estaban acostumbrados a archivos de Excel para calcular incentivos para conductores, y el equipo implementó un motor de hojas de cálculo que ejecutaba archivos XLS y fórmulas en el navegador, en vez de traducir manualmente cientos o miles de fórmulas a JavaScript.
- La causa de que los resultados difirieran sutilmente de Excel era que los data scientists habían realizado una regresión lineal con referencias circulares, y se ajustó el comportamiento para recalcular iterativamente hasta converger, como Excel.
- Incluso el código bien hecho puede eliminarse si desaparece el problema de negocio que buscaba resolver; el valor de la ingeniería está más cerca de resolver problemas que de la vida útil del código.
La herramienta interna de datos que sostenía a Uber China
- Tras unirme a Uber en 2016, empecé a trabajar como el primer ingeniero frontend del equipo Crystal Ball.
- El equipo tenía unas 4 personas y la mayoría tenía una fuerte orientación backend.
- Mi rol era convertir herramientas internas en UI que la gente de la empresa pudiera usar de verdad.
- En ese momento, los data scientists descargaban datos desde Vertica y ejecutaban modelos en R durante toda la noche en varias laptops.
- Por la mañana, solo las laptops donde el modelo no se había caído producían datos que quizá podían usarse ese día.
- Las laptops que fallaban no generaban los datos necesarios, y eso llevaba a una situación en la que la empresa perdía dinero.
- R-Crusher, lo que el equipo estaba construyendo, era algo parecido a un sistema de CI que descargaba y ejecutaba código mediante llamadas a API y generaba archivos de resultados.
- Wesley, el frontend de R-Crusher, tuvo una primera versión lista a las pocas semanas de mi llegada.
- Durante los siguientes 6 o 7 meses se sumaron funciones para usuarios, herramientas de depuración y la expansión del equipo frontend.
El mercado chino y el cálculo de incentivos para conductores
- En 2016, dos grandes ejes dentro de Uber eran la reescritura/rediseño de la app y Uber China.
- El trabajo del equipo Crystal Ball, en última instancia, era para apoyar a Uber China.
- R-Crusher era una herramienta para obtener los datos necesarios para competir con Didi.
- China era una oportunidad importante para Uber, y parte de los datos necesarios iba a salir de R-Crusher.
- En verano llegó un nuevo requerimiento.
- Había un modelo que generaba durante la noche datos de predicción de demanda de viajes en China.
- Esos datos no eran útiles por sí solos, pero al insertarlos en una pestaña específica de una hoja de cálculo de Excel se convertían en una herramienta interactiva para calcular incentivos para conductores.
- La responsable de finanzas pidió que esa hoja de cálculo se incorporara dentro de Wesley.
- Dijo que los equipos de ciudades solo sabían usar Excel y pidió: “háganlo como Excel”.
- Aunque se explicó que faltaba tiempo de ingeniería, la respuesta fue que, si no tenían la herramienta todos los días, perderían millones de dólares.
Imitar Excel dentro del navegador
- No había tiempo para pasar la hoja de cálculo a código Python o R en el backend, así que había que escribir mucho JavaScript en el frontend.
- El prototipo Box Sums, creado antes en Box, sirvió de base.
- Tenía una UI simple de hoja de cálculo basada en React y un motor básico de fórmulas.
- Al soltar un archivo XLS/XLSX en la página, una librería de Node parseaba su contenido.
- La implementación para Uber no buscaba ser Excel en sí, sino comportarse de manera similar a Excel.
- Leía archivos XLS como entrada.
- Ejecutaba fórmulas de Excel sobre los datos.
- El backend entregaba los datos de demanda de viajes como un arreglo bidimensional, y el frontend los introducía en el motor de fórmulas como si fueran una pestaña oculta.
- Todas las celdas salvo las que el usuario debía manipular se dejaban en modo de solo lectura.
- La clave era no traducir manualmente a JavaScript cientos o miles de fórmulas densas.
- Durante la implementación se extrajeron las fórmulas del archivo XLS y se agregaron al motor de fórmulas las funciones y la sintaxis necesarias.
-
Extensiones de sintaxis de Excel
- Referencias absolutas a celdas
- Referencias a celdas en otras hojas
- Sintaxis de hojas de cálculo que no existía en la demo original de Box
-
Números casi correctos, pero incorrectos, y referencias circulares
- En la primera comparación, los resultados de Excel y los del motor propio diferían por muy poco.
- Cuando Excel arrojaba
3.03, el motor propio arrojaba3.01. - Cuando Excel arrojaba
1.002, el motor propio arrojaba1.000.
- Cuando Excel arrojaba
- Los valores casi correctos eran más difíciles de manejar que los valores totalmente equivocados.
- Era más probable que se tratara de una diferencia sutil de cálculo que de un simple error de lógica.
- Las pruebas unitarias pasaban, y la diferencia entre los double de JavaScript y la representación de punto flotante de Excel tampoco era la causa.
- Tras preguntarle a un data scientist, apareció la causa.
- La hoja de cálculo estaba usando referencias circulares para realizar una regresión lineal.
- Excel no siempre trata las referencias circulares como errores.
- Si el valor calculado converge con una diferencia por debajo de cierto epsilon, deja de iterar y lo trata como exitoso.
- La implementación cambió para detectar el grafo de dependencias circulares y comparar la diferencia entre el valor calculado anterior y el nuevo.
- Si la diferencia era suficientemente pequeña, se usaba el valor nuevo.
- Si no, se aumentaba la cantidad de iteraciones y se seguía calculando.
- El umbral máximo de iteraciones se fijó en 1000.
- El cambio tomó alrededor de un día y medio, y la salida coincidió con Excel.
- Se escribieron pruebas y se integró en Wesley.
- El proyecto se entregó en la segunda semana de julio.
Un requerimiento de seguridad tras el lanzamiento y un descarte repentino
- La herramienta efectivamente se lanzó, y miembros de los equipos de ciudades de Uber China iniciaron sesión y la usaron.
- Tengo entendido que los números generados se usaron para incentivos de conductores.
- Fue en la tercera semana de julio.
- En la última semana de julio, la responsable de finanzas señaló como problema que, al hacer clic en una celda, se pudiera ver la fórmula.
- Se comunicó la preocupación de que empleados de Didi se postularan como pasantes en Uber China para extraer datos.
- Ese modelo de amenaza no se había compartido previamente con el equipo de ingeniería.
- Para proteger por completo las fórmulas, habría que haber movido el cálculo al servidor, pero eso estaba fuera del alcance del pedido.
- La corrección inmediata se manejó ocultando la fórmula en la UI al hacer clic en una celda.
- En la primera semana de agosto de 2016, Uber China fue vendida a Didi.
- Muchos empleados se enteraron primero por notificaciones de noticias.
- Unas horas después, la transacción se anunció por correo interno.
- Con la desaparición de Uber China, esa UI se eliminó de Wesley.
- Era una UI a medida para un trabajo de datos que no volvería a ejecutarse.
- No hubo más pedidos para recrear Excel en el navegador.
Resolver problemas más que prolongar la vida del código
- En ese momento no sentí una gran pérdida ni decepción.
- Lo primero que pensé fue que quería publicar el código en GitHub, y después pasé a lo siguiente.
- Sí hubo una pequeña pena de que el código trabajado se usara por poco tiempo y desapareciera.
- El código que escriben los ingenieros algún día se convierte en código legacy.
- Alguien, en algún momento, puede sentir alegría al eliminar ese código.
- Incluso si el código está bien hecho, mantenerlo por mucho tiempo no es un objetivo en sí mismo.
- Crecer como ingeniero está conectado con usar la tecnología para crear mejor valor de negocio.
- El valor de negocio se crea de muchas formas: entregables técnicos, colaboración, mentoring, apoyo al equipo, etc.
- Después de que desapareció Uber China, ya no quedaba valor de negocio por crear con este proyecto.
- Seguir impulsándolo no habría ayudado ni a la persona ni a la empresa.
- La expresión de DevOps “Cattle, not pets” también aplica al código.
- El código es un medio para realizar un trabajo, y si ese trabajo deja de ser útil, debe estar listo para retirarse.
- Si por apego emocional tratamos el código como una mascota, terminamos moviéndonos en contra de la comprensión del negocio.
Las preguntas que deja un proyecto descartado
- No hace falta ver de inmediato como fracaso el hecho de que se haya eliminado un proyecto.
- Un trabajo descartado deja estas preguntas:
- ¿Construimos algo que no cumplía las restricciones del proyecto?
- ¿Construimos lo que se nos pidió, pero el pedido estaba mal desde el principio?
- ¿Se entendió mal el problema central?
- ¿La solución solicitada resolvía la necesidad real de los usuarios finales?
- ¿Hubo preguntas que no se hicieron a los stakeholders?
- ¿Las expectativas eran imprecisas o ambiguas?
- ¿Hacía falta tanta robustez como la que entregamos?
- ¿Habría bastado una solución más simple o menos ingeniosa?
- ¿Definimos mal los criterios de éxito?
- ¿Había criterios de éxito más allá de “construir lo que se pidió”?
- Si vemos el cierre de un proyecto solo como un fracaso, perdemos la oportunidad de aprender dónde se torcieron los problemas no técnicos.
- Incluso una pieza creada con gran precisión puede eliminarse si no funciona con fluidez dentro de un sistema más grande.
1 comentarios
Opiniones en Hacker News
La mejor cita fue esta: “La gente que trabaja en Didi postula como pasantes en Uber China y luego se lleva nuestros datos. No podemos dejar que vean las fórmulas. ¡Si no, copiarán exactamente lo que hacemos!”
Esto es totalmente cierto. La gente en EE. UU. no conoce bien el nivel de espionaje económico e industrial que ocurre todos los días en China. Hacia mediados de los 2000, mientras respondía a un incidente de intrusión separado en una empresa tecnológica cuyo nombre no puedo revelar, me dijeron: “Abrimos un centro tecnológico en Xinjiang y últimamente ha habido una cantidad inusualmente alta de credenciales de acceso perdidas”. Cuando pregunté: “¿Han considerado que quizá no se perdieron, sino que las vendieron por dinero?”, se hizo el silencio.
No sé si los ejecutivos lo saben y no les importa, o si simplemente son incompetentes, pero China ha productizado el espionaje industrial a gran escala. Hace poco GE Aviation también fue víctima: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
Después fundan una empresa en China, reciben inversión china y crean casi el mismo producto para el mercado chino. Por ejemplo, están los casos de Thoratec/Abbot Heartmate III y CH Biomedical, o Auris/Verb/J&J Robotic & Digital Solutions y Renovo Surgical.
Irónicamente, algunas de estas empresas, después de tener éxito en China, intentan vender y competir en EE. UU. y Europa. Ya no es un secreto ni un arreglo por debajo de la mesa; en nuestra industria ocurre abiertamente y, en general, se acepta como “así son las cosas”.
Otra cuestión es que a las empresas extranjeras les resulta muy difícil proteger sus activos al hacer negocios en China. Por eso las empresas inteligentes ni siquiera intentan hacerlo directamente y muchas veces licencian a una empresa china para el mercado chino. Así al menos existe alguna posibilidad de que no les roben todo.
Hace tiempo, en la agencia donde trabajaba, contratamos a un diseñador industrial para hacer una carcasa bonita para hardware iBeacon. El resultado fue excelente.
Encargamos el moldeo por inyección a una empresa china y las muestras eran bastante buenas, así que decidimos usarlas. Pero unas semanas después vimos nuestra carcasa a la venta en Alibaba/AliExpress.
No estoy diciendo que Occidente u otros países sean perfectos, pero no es de eso de lo que estamos hablando ahora. Todas las personas que conozco que han trabajado con manufactura y negocios en China han vivido cosas como “nos copiaron”, “vendieron nuestro trabajo a otros” o “entregaron x de una calidad inferior a la acordada”.
La réplica siempre termina siendo “pero Occidente también hace X” o “eso es racismo”.
A las empresas chinas, especialmente las que venden en Ali-X, les encanta esta estructura. Porque pueden tomar propiedad intelectual gratis y desplazar por precio al fabricante original del equipo. También es común que copien diseños de makers publicados en Tindie y otros sitios, y luego aparezcan en Ali.
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
Al leer este texto esperaba una historia sobre cómo se retiraba y eliminaba código personalizado complejo, pero el autor, contra lo esperado, creció como ingeniero.
El dicho de DevOps “Cattle, not pets” encaja perfecto acá. El código y los productos hechos con ese código no son mascotas, sino ganado. Hacen un trabajo y, cuando ese trabajo deja de ser útil, están listos para retirarse. Si tratas el código como una mascota por razones sentimentales, estás actuando directamente en contra de los intereses del negocio.
Mucho código es divertido de escribir y muchos problemas son divertidos de resolver. Pero un negocio, especialmente una startup, necesita un enfoque extremo. Mi carrera, en la práctica, se parece bastante a estar sentado en salas de juntas diciéndoles a ingenieros jóvenes y entusiastas que no construyan algo. Es un poco deprimente, pero también es necesario.
Un buen ingeniero puede resolver cualquier problema con código ingenioso. Un gran ingeniero entiende que ciertos problemas en realidad no son problemas, y que tal vez bastaba con un enlace de descarga XLS actualizado a diario.
Estaba creando un sistema de monitoreo para un servicio que hospedábamos internamente, y mi jefe quería comprar una pequeña utilidad para vigilar una parte menor de nuestro entorno. Me molestó un poco que quisiera pagar por algo que yo podía hacer.
Mi jefe me preguntó: “¿Cuánto tardarías en escribirlo y probarlo?”, y yo respondí: “Probablemente una semana; quizá un poco más si aparece algo complicado”. Entonces me preguntó: “Esa herramienta cuesta 500 dólares. ¿Cuánto valen tus 40 horas?”.
Ahí entendí la lección, y desde entonces nunca volví a construir en la empresa algo que se pudiera comprar más barato.
La checklist al final de la página de Substack tampoco es suficiente para este nivel de identificación de requisitos. Esas preguntas solo describen la situación, y hacerlas no habría llevado a esta solución simple. Pensar en términos de checklist es una muleta y complica demasiado el problema.
Aquí las señales importantes eran todas organizacionales y sociales; no era un problema que se resolviera mejorando el proceso. Alguien que no participa en los detalles de implementación no puede responder preguntas sobre los detalles de implementación.
“Solo hazlo como Excel” es una respuesta de baja calidad de alguien con objetivos completamente distintos. Había que consultar con alguien más cercano a los usuarios reales y construir la objeción desde ahí. Lo que faltó fue la capacidad de reconocer supuestos débiles y el valor de no escribir código deliberadamente hasta que los detalles estuvieran lo suficientemente fijados como para que todas las partes estuvieran de acuerdo. No hay que decirle simplemente que sí al “responsable”.
En 2006 ya tuve una larga conversación para convencer a alguien de no ir por ese camino, y en 2026 alguien volverá a intentarlo.
La capacidad de detenerse y pensar “¿cómo resolvieron otros este mismo problema?” es una parte enorme de crecer como desarrollador; ojalá en la escuela se enfocaran más en eso.
No se puede concluir que la elección de implementación haya sido mala solo porque se describe que se terminó con éxito y a tiempo dentro de un plazo corto. Más bien fue tan exitosa que implementó demasiadas funciones de Excel, y luego se corrigió eliminándolas. ¿Cómo habrías eliminado eso con un enlace de descarga XLS?
El punto central es no encariñarse demasiado con el código, y en algunas situaciones puede significar “no lo construyas tú, usa un enlace de descarga XLS”, pero no es todo.
Me sorprendieron mucho partes como “No pasó nada, pero guardé ese código por si algún día lo usaba. Mi idea era adaptarlo para el caso de uso de Uber” y “Mi primera reacción fue publicar el código en GitHub”.
¿Ese código no era propiedad de Box o de Uber? El autor no menciona haber pedido permiso antes de publicarlo con licencia MIT.
Si Uber quiere un JavaScript de miles de líneas que ni siquiera salió de ellos, que tiene más de medio año y que se usó menos de un mes, pueden mandarme una carta.
La parte de “él simplemente no podía creer que yo hubiera escrito un motor completo de hojas de cálculo que corría en el navegador” también me cuesta creerla, y no en el buen sentido
Con Apache POI se puede ejecutar Excel en modo headless. En Java puedes cargar hojas e interactuar con ellas programáticamente; en un trabajo anterior lo usamos exactamente por la misma razón. Funciones, referencias de celdas, etc., todo funcionaba bien
Solo tuvo suerte de encontrar el problema de
circ. ¿Qué va a hacer con todas las pequeñas particularidades ocultas de Excel que encuentre de aquí en adelante? ¿De verdad va a crear y mantener en JS una réplica completa de Excel? ¿Ese es realmente el objetivo del equipo de frontend?Con buscar un poco, parece que aquí se podría haber evitado más del 90% del trabajo. Y, de paso, tal vez lo podría haber tomado el equipo de backend
Uber operaba sus propios centros de datos. Conseguir una máquina o VM con Windows para ejecutar Excel de verdad habría requerido un milagro. Yo podía levantar un nuevo servicio de frontend en unos 30 minutos, y ya tenía algo de código funcionando, así que no era empezar totalmente desde cero. También había que considerar que el sistema tenía que ser usado al mismo tiempo por varias personas con distintos conjuntos de datos
Si hubieran seguido pidiendo más funciones y paridad con Excel, lo habría reevaluado, pero no fue así
No espero que mucha gente tome la misma decisión que tomé yo. Pero funcionó, y funcionó sorprendentemente bien. Si del artículo solo se quedaron con “era un proyecto grande y complejo”, entonces el texto no transmitió bien el mensaje que yo quería dar
Yo probablemente habría cuestionado más la especificación de la UI y habría insistido en ejecutar Excel por detrás. Pero cuando hay que ingresar muchos números por todos lados, sí es una interfaz familiar
Siempre me pareció interesante este artículo sobre cómo crear una hoja de cálculo en 100 líneas de F#: https://tomasp.net/blog/2018/write-your-own-excel/ Ampliarlo al conjunto de funciones necesario aquí parece manejable
Al final creó una réplica casera de “Excel” como UI del modelo, porque “los equipos de ciudad solo saben usar Excel”
Yo habría hecho lo contrario. Habría conectado Excel a los datos exportados por el modelo para que los equipos de ciudad pudieran seguir usando Excel de verdad. Creo que la mayoría de los equipos financieros trabajan así
Para quienes tengan curiosidad, documentación sobre referencias circulares en Excel: https://support.microsoft.com/en-us/office/remove-or-allow-a...
Si no estás familiarizado con el cálculo iterativo, probablemente no quieras dejar una referencia circular tal cual. Puedes activar el cálculo iterativo, pero tienes que decidir cuántas veces recalcular las fórmulas. Si activas el cálculo iterativo sin cambiar el número máximo de iteraciones ni el cambio máximo, Excel deja de calcular después de 100 iteraciones o cuando todos los valores de la referencia circular cambian menos de 0.001 entre iteraciones, lo que ocurra primero. De todos modos, puedes controlar tanto el número máximo de iteraciones como la cantidad de cambio aceptable
Me pregunto si el autor habría visto esta situación de otra manera si Uber o Box hubieran afirmado que ese código era suyo. Aunque el código nunca haya alcanzado su verdadero potencial, el hecho de que al menos todo el mundo pueda verlo y reconocerlo parece ofrecer cierta catarsis.
Cuando trabajaba como pasante, una vez creé un lenguaje de programación completo. Tenía evaluación diferida y recolección de basura, y también rarezas específicas de la aplicación, como que las direcciones MAC sin comillas fueran sintaxis válida.
No tenía bytecode ni JIT ni nada por el estilo; el intérprete recorría el árbol sintáctico y hacía push/pop de valores en una pila, pero era lo suficientemente rápido para lo que hacíamos. El intérprete estaba escrito en ANSI C puro, y Valgrind quedaba muy satisfecho.
Puede que haya quedado completamente olvidado, o puede que se haya vuelto central para la infraestructura técnica de esa empresa. Ese código nunca salió del laboratorio aislado que yo había creado, así que no tengo forma de saberlo. Hace tres años, recién egresado de la universidad, era por mucho el “software realmente útil” más genial que había escrito, y aún hoy sigue estando entre los mejores. A veces me pregunto qué habrá sido de él.
El autor parece creer erróneamente que haberle preguntado a un gerente medio, o incluso a uno de alto rango, “¿quieren esto?”, y que ese gerente haya respondido “no”, es legalmente vinculante para la empresa.
Me llegó la frase: “Es fácil tratar el código especialmente ingenioso o elegante como una obra maestra. De hecho, puede ser un hermoso adorno. Pero los ingenieros no estamos en el negocio de crear adornos hermosos, sino en el de generar resultados”.
Dicho eso, cualquiera que haya visto mi código sabe que me gusta que tanto el código como lo que hace sean muy bonitos. Como normalmente escribo código que yo mismo voy a mantener, necesito poder entenderlo incluso un año después.
Ahora estoy en la etapa final de un proyecto que no voy a presentar aquí ni del que pretendo llevarme gran mérito, y es una cosa realmente impresionante. Llegó a ser así porque nadie paga por él y nadie gana dinero con él.
El dinero arruina todo y, al mismo tiempo, lo hace todo posible.
Un texto realmente excelente desde la perspectiva del antiguo equipo de BI de Uber. Yo estaba en el equipo de Vertica en esa época, y la cantidad de esfuerzo dedicado a los incentivos era mareante. Era común hablar de que se perdían millones de dólares al día por downtime, funcionalidades de producto y ancho de banda de ingeniería.
Especialmente durante la época de Uber China, habría sido muy natural que un director pidiera exactamente una hoja de cálculo como UI. Yo mismo cargaba en Vertica precios de FX desde una hoja de cálculo que le llegaba por correo al equipo cada mes. Como no había ancho de banda para invertir el flujo de control con una recolección automática, ese proceso permaneció durante más de un año.
La frase “hasta el día de hoy no he visto nada tan bien diseñado como el sistema interno de aplicaciones de Uber. Desde empezar hasta tener un Hello World corriendo con CI/CD completo en un subdominio de *.uberinternal.com tomaba menos de 30 minutos” me dio un poco de calidez.
En aquel entonces estuve involucrado en todo eso en Uber.