Criei um Excel para a Uber, mas ele logo foi descartado
(basta.substack.com)- Em 2016, a organização de Business Intelligence da Uber criou uma ferramenta para executar modelos em R e uma interface parecida com o Excel para usar rapidamente os dados necessários à competição da Uber China, mas a funcionalidade foi removida pouco depois que a Uber China foi vendida para a Didi
- O R-Crusher era um sistema interno que buscava substituir o fluxo instável em que cientistas de dados baixavam dados do Vertica para notebooks e rodavam modelos em R durante a noite por uma ferramenta de execução baseada em API
- As equipes das cidades na China estavam acostumadas com arquivos do Excel para calcular incentivos de motoristas, e a equipe implementou um motor de planilha que executava arquivos XLS e fórmulas no navegador, em vez de portar diretamente centenas ou milhares de fórmulas para JavaScript
- A razão de os resultados divergirem sutilmente do Excel era que os cientistas de dados faziam regressão linear com referências circulares, e isso foi ajustado para funcionar como o Excel, com cálculos iterativos até a convergência
- Mesmo um código bem feito pode ser removido se o problema de negócio que ele resolvia desaparecer; o valor da engenharia está mais próximo de resolver problemas do que da longevidade do código
A ferramenta interna de dados que sustentava a Uber China
- Depois de entrar na Uber em 2016, passei a trabalhar na equipe Crystal Ball como o primeiro engenheiro de front-end
- A equipe tinha cerca de 4 pessoas e a maioria tinha um perfil fortemente voltado a back-end
- Meu papel era transformar ferramentas internas em interfaces que as pessoas da empresa pudessem realmente usar
- Na época, os cientistas de dados baixavam dados do Vertica e rodavam modelos em R durante a noite em vários notebooks
- De manhã, só o notebook em que o modelo não tinha quebrado produzia dados que talvez pudessem ser usados naquele dia
- Os notebooks que falhavam não conseguiam gerar os dados necessários, e isso levava a situações em que a empresa perdia dinheiro
- O R-Crusher que a equipe estava criando era mais parecido com um sistema de CI que baixava código via chamadas de API, executava esse código e gerava arquivos de resultado
- O Wesley, front-end do R-Crusher, teve sua primeira versão pronta poucas semanas depois da minha chegada
- Depois disso, vieram 6 a 7 meses de recursos para usuários, ferramentas de depuração e expansão da equipe de front-end
O mercado chinês e o cálculo de incentivos para motoristas
- Em 2016, dois grandes focos internos da Uber eram a reescrita/redesign do app e a Uber China
- O trabalho da equipe Crystal Ball, no fim, existia para apoiar a Uber China
- O R-Crusher era uma ferramenta para garantir os dados necessários para competir com a Didi
- A China era uma oportunidade importante para a Uber, e parte dos dados necessários sairia do R-Crusher
- No verão, surgiu uma nova demanda
- Havia um modelo que gerava durante a noite dados de previsão de demanda por corridas na China
- Sozinhos, esses dados não eram úteis; ao serem inseridos em uma aba específica de uma planilha do Excel, tornavam-se uma ferramenta interativa para calcular incentivos de motoristas
- O responsável financeiro exigiu que essa planilha fosse colocada dentro do Wesley
- As equipes das cidades diziam que só sabiam usar Excel e pediam: “façam parecer Excel”
- Explicamos que não havia tempo de engenharia suficiente, mas a resposta foi que sem a ferramenta a empresa perderia milhões de dólares por dia
Imitando o Excel dentro do navegador
- Não havia tempo para portar a planilha no back-end para código Python ou R, e a situação acabou exigindo muito JavaScript no front-end
- Um protótipo anterior chamado Box Sums, feito na Box, serviu de base
- Ele tinha uma interface simples de planilha baseada em React e um motor básico de fórmulas
- Ao soltar arquivos XLS/XLSX na página, uma biblioteca Node analisava o conteúdo
- A implementação para a Uber não mirava o Excel em si, mas um comportamento próximo ao Excel
- Lia arquivos XLS como entrada
- Executava fórmulas do Excel sobre os dados
- O back-end fornecia os dados de demanda por corridas em um array bidimensional, e o front-end os inseria no motor de fórmulas como se fossem abas ocultas
- Com exceção das células que os usuários precisavam manipular, todo o resto era somente leitura
- O ponto central era evitar traduzir manualmente para JavaScript centenas ou milhares de fórmulas densamente conectadas
- No processo de implementação, foram extraídas as fórmulas do arquivo XLS e adicionadas ao motor de fórmulas as funções e sintaxes necessárias
-
Extensões da sintaxe do Excel
- Referências absolutas de células
- Referências a células de outras planilhas
- Sintaxe de planilha que não existia na demo original da Box
-
Números quase certos, mas errados, e referências circulares
- Na primeira comparação, os resultados do Excel e do motor próprio diferiam muito pouco
- Quando a saída do Excel era
3.03, a saída própria era3.01 - Quando a saída do Excel era
1.002, a saída própria era1.000
- Quando a saída do Excel era
- Valores quase certos eram mais complicados do que valores totalmente errados
- Era mais provável que a causa fosse uma diferença sutil de cálculo do que um erro lógico simples
- Os testes unitários passavam, e a diferença entre o double do JavaScript e a representação de ponto flutuante do Excel também não era a causa
- Depois de perguntar a um cientista de dados, a causa veio à tona
- A planilha estava usando referências circulares para fazer regressão linear
- O Excel nem sempre trata referências circulares como erro
- Se os valores calculados convergem até uma diferença abaixo de um certo epsilon, ele interrompe os cálculos iterativos e trata isso como sucesso
- A implementação foi alterada para detectar o grafo de dependências circulares e comparar o valor calculado anterior com o novo
- Se a diferença fosse pequena o suficiente, o novo valor era usado
- Caso contrário, o número de iterações aumentava e o cálculo continuava
- O limite de iterações foi definido em 1000
- A mudança levou cerca de um dia e meio, e a saída passou a coincidir com a do Excel
- Escrevemos testes e integramos tudo ao Wesley
- O projeto foi entregue na segunda semana de julho
Exigência de segurança após o lançamento e descarte repentino
- A ferramenta de fato foi lançada, e membros das equipes urbanas da Uber China entravam e a usavam
- Pelo que sei, os números gerados foram usados nos incentivos de motoristas
- Isso foi na terceira semana de julho
- Na última semana de julho, o responsável financeiro reclamou que clicar numa célula mostrava a fórmula
- Foi levantado o temor de que um funcionário da Didi se candidatasse como estagiário da Uber China e extraísse os dados
- Esse modelo de ameaça não havia sido compartilhado previamente com a equipe de engenharia
- Para proteger completamente as fórmulas, seria preciso mover os cálculos para o servidor, mas isso estava fora do escopo do pedido
- A correção imediata foi simplesmente fazer com que a fórmula não aparecesse ao clicar na célula pela UI
- Na primeira semana de agosto de 2016, a Uber China foi vendida para a Didi
- Muitos funcionários souberam primeiro por notificações de notícias
- Algumas horas depois, a transação foi anunciada por e-mail interno
- Com o desaparecimento da Uber China, aquela UI foi removida do Wesley
- Era uma interface sob medida para um trabalho de dados que nunca mais seria executado
- Nunca mais houve um pedido para recriar o Excel no navegador
Resolver problemas importa mais do que a vida útil do código
- Na época, não houve um grande sentimento de perda ou decepção
- Meu primeiro impulso foi pensar em publicar o código no GitHub, e depois simplesmente seguir para a próxima tarefa
- Houve um pequeno arrependimento por um código trabalhoso ter sido usado por pouco tempo e depois sumido
- O código que engenheiros escrevem um dia vira código legado
- Em algum momento, alguém pode até sentir alegria ao removê-lo
- Mesmo um código bem feito não tem como objetivo principal permanecer por muito tempo
- Crescer como engenheiro está ligado a usar tecnologia para gerar melhor valor de negócio
- Valor de negócio pode ser criado de várias formas: entregas técnicas, colaboração, mentoria, apoio ao time e mais
- Depois que a Uber China desapareceu, não restava mais valor de negócio a criar com esse projeto
- Continuar insistindo nele não ajudaria nem a mim nem à empresa
- A expressão de DevOps “Cattle, not pets” também se aplica ao código
- Código é um meio para realizar um trabalho, e quando esse trabalho deixa de ser útil, ele deve estar pronto para se aposentar
- Tratar código como animal de estimação por apego emocional vai na direção contrária de entender o negócio
As perguntas que um projeto descartado deixa para trás
- O fato de um projeto ter sido removido não significa automaticamente que ele foi um fracasso
- Um trabalho descartado deixa as seguintes perguntas
- Foi criado algo que não atendia às restrições do projeto?
- Foi feito o que pediram, mas o pedido em si estava errado?
- O problema central foi mal compreendido?
- A solução solicitada realmente resolvia a necessidade do usuário final?
- Havia perguntas que não foram feitas às partes interessadas?
- As expectativas estavam imprecisas ou ambíguas?
- Era mesmo necessário o nível de robustez que foi entregue?
- Uma solução mais simples ou menos engenhosa teria sido suficiente?
- Os critérios de sucesso foram definidos de forma errada?
- Havia algum critério de sucesso além de “construir o que foi pedido”?
- Se você olhar para o fim do projeto apenas como fracasso, perde a chance de aprender em que ponto os fatores não técnicos saíram dos trilhos
- Até componentes feitos com sofisticação podem ser removidos se não funcionarem de forma fluida dentro de um sistema maior
1 comentários
Opiniões no Hacker News
A melhor citação foi esta: “Pessoas que trabalham na Didi se candidatam como estagiárias da Uber China e depois levam nossos dados. Não podemos deixá-las ver as fórmulas. Senão, vão copiar exatamente o que fazemos!”
Isso é muito verdade. Os americanos não têm muita noção do nível de espionagem econômica e industrial que acontece todos os dias na China. Lá por meados dos anos 2000, enquanto eu respondia a um incidente de invasão separado em uma empresa de tecnologia que não posso identificar, ouvi alguém dizer: “abrimos um centro de tecnologia em Xinjiang e, ultimamente, tem havido um número incomum de crachás de acesso perdidos”. Perguntei: “vocês já consideraram que talvez eles não tenham sido perdidos, mas vendidos por dinheiro?”, e houve silêncio
Não sei se os executivos sabem e não se importam, ou se são simplesmente incompetentes, mas a China transformou a espionagem industrial em produto em larga escala. Recentemente, a GE Aviation também foi vítima: https://www.cincinnati.com/story/news/2022/11/16/accused-chi...
Em seguida, abrem uma empresa na China, recebem investimento chinês e criam praticamente o mesmo produto para o mercado chinês. Exemplos incluem Thoratec/Abbot Heartmate III e CH Biomedical, Auris/Verb/J&J Robotic & Digital Solutions e Renovo Surgical
Ironicamente, algumas dessas empresas, depois de terem sucesso na China, tentam vender e competir nos EUA e na Europa. Hoje isso não é segredo nem acordo de bastidores; no nosso setor, acontece abertamente e, em geral, é aceito como “é assim mesmo”
Outra questão é que é muito difícil para uma empresa estrangeira proteger seus ativos ao fazer negócios na China. Por isso, empresas sensatas muitas vezes nem tentam fazer isso diretamente e licenciam para empresas chinesas o que é destinado ao mercado chinês. Assim ao menos existe alguma chance de não terem tudo roubado
Em uma agência onde trabalhei antes, contratamos um designer industrial para criar uma carcaça bonita para hardware iBeacon. O resultado ficou excelente
Encomendamos a moldagem por injeção a uma empresa chinesa, e as amostras estavam muito boas, então decidimos usá-las. Algumas semanas depois, vimos a nossa carcaça sendo vendida no Alibaba/AliExpress
Não estou dizendo que o Ocidente ou outros países sejam perfeitos, mas não é disso que se trata aqui. Todas as pessoas que conheço e que trabalharam com manufatura e negócios na China passaram por coisas como “copiaram”, “venderam nosso trabalho para outros” ou “entregaram uma versão de x de qualidade inferior à combinada”
As objeções sempre acabam em “mas o Ocidente também faz X” ou “isso é racismo”
As empresas chinesas, especialmente as que vendem no Ali-X, adoram essa estrutura. Porque conseguem pegar propriedade intelectual de graça e tirar do mercado o fabricante original do equipamento competindo por preço. Projetos de makers publicados no Tindie e afins também são frequentemente copiados e aparecem no Ali
https://www.nytimes.com/2017/03/03/technology/uber-greyball-...
https://www.theverge.com/2014/8/12/5994077/uber-cancellation...
Ao ler este texto, eu esperava uma história sobre código customizado complexo sendo desmontado e deletado, mas, ao contrário do que eu imaginava, o autor acabou crescendo como engenheiro
O ditado de DevOps “Cattle, not pets” se encaixa perfeitamente aqui. Código e os produtos criados com ele não são animais de estimação, são gado. Eles fazem o trabalho e, quando esse trabalho deixa de ser útil, estão prontos para se aposentar. Se você trata código como um pet por razões sentimentais, está agindo diretamente contra os interesses do negócio
Muito código é divertido de escrever, e muitos problemas são divertidos de resolver. Mas um negócio, especialmente uma startup, precisa ser extremamente focado. Minha carreira, na prática, tem sido quase sentar em salas de reunião e dizer a engenheiros jovens e empolgados para não construir. É um pouco deprimente, mas também é algo necessário
Um bom engenheiro consegue resolver qualquer problema com código inteligente. Um engenheiro excelente entende quais problemas na verdade não são problemas, e que talvez um link de download de XLS atualizado diariamente já fosse suficiente
Eu estava criando um sistema de monitoramento para um serviço hospedado internamente, e meu chefe queria comprar um pequeno utilitário que monitorava uma parte trivial do nosso ambiente. Fiquei meio ofendido com a ideia de pagar por algo que eu mesmo podia fazer
Meu chefe perguntou: “Quanto tempo levaria para escrever e testar isso?”, e eu respondi: “Provavelmente uma semana; se aparecer algo complicado, talvez um pouco mais”. Então ele perguntou: “Essa ferramenta custa 500 dólares. Quanto custam 40 horas do seu salário?”
Foi ali que a ficha caiu e, desde então, nunca mais construí algo internamente que a empresa pudesse comprar por menos
O checklist no fim da página do Substack também não basta para esse nível de levantamento de requisitos. Aquelas perguntas apenas descrevem a situação; só por fazê-las, você não teria chegado a essa solução simples. Pensamento por checklist é uma muleta e complica demais o problema
Aqui, os sinais importantes eram todos organizacionais e sociais; não era uma questão de melhorar o processo. Quem não está envolvido nos detalhes de implementação não consegue responder perguntas sobre detalhes de implementação
“É só fazer como o Excel” é uma resposta de baixa qualidade dada por alguém com objetivos completamente diferentes. Era preciso conversar com alguém mais próximo dos usuários reais e construir a contraposição a partir daí. O que faltou foi reconhecer suposições fracas e ter a coragem de deliberadamente não escrever código até que os detalhes estivessem fixados o bastante para todas as partes concordarem. Não dá para simplesmente dizer sim ao “responsável”
Em 2006, eu já tive uma longa conversa tentando convencer alguém a não seguir esse caminho, e em 2026 alguém vai querer fazer isso de novo
A capacidade de parar e pensar “como outras pessoas resolveram exatamente este problema?” é uma parte enorme do amadurecimento como desenvolvedor, e eu gostaria que as escolas dessem mais foco a isso
Só pela descrição de que ele foi concluído com sucesso e no prazo curto, não dá para concluir que as escolhas de implementação foram ruins. Pelo contrário: ele foi tão bem-sucedido que implementou recursos demais do Excel, e a história é que depois isso foi corrigido removendo esses recursos. Como você removeria isso de um link de download de XLS?
O ponto central é não se apegar demais ao código; em algumas situações, isso pode significar “não construa você mesmo, use um link de download de XLS”, mas não é só isso
Achei muito surpreendentes os trechos “Nada aconteceu, mas guardei aquele código para o dia em que talvez o usasse. Minha ideia era adaptar esse código às necessidades da Uber” e “minha primeira reação foi publicar o código no GitHub”
Esse código não era propriedade da Box ou da Uber? O autor não menciona ter recebido permissão antes de publicá-lo sob a licença MIT
Se a Uber quer um JavaScript de milhares de linhas, que nem saiu deles, escrito mais de meio ano antes e usado por menos de um mês, é só mandar uma carta
O trecho “ele simplesmente não conseguia acreditar que eu tinha escrito um motor de planilhas completo que rodava no navegador” também é difícil de acreditar para mim, e não no bom sentido
Com Apache POI, dá para rodar o Excel em modo headless. Em Java, é possível carregar planilhas e interagir com elas programaticamente; usei exatamente por esse mesmo motivo em um emprego anterior. Funções, referências de células etc. funcionavam muito bem
Ele só teve sorte de encontrar o problema de “circ”. E quanto a todas as pequenas peculiaridades ocultas do Excel que vão aparecer daqui para frente? Vai mesmo criar e manter uma cópia completa do Excel em JS? Esse é mesmo o objetivo da equipe de frontend?
Com uma busca rápida, provavelmente dava para evitar mais de 90% do trabalho aqui. De quebra, a equipe de backend poderia ter assumido isso
A Uber operava seus próprios data centers. Conseguir uma máquina Windows ou uma VM para rodar o Excel de verdade teria exigido um milagre. Eu conseguia colocar um novo serviço de frontend no ar em cerca de 30 minutos, e já havia um pouco de código rodando, então não era começar totalmente do zero. Também é preciso considerar que esse sistema precisava ser usado simultaneamente por várias pessoas com conjuntos de dados diferentes
Se continuassem pedindo mais recursos e paridade com o Excel, eu teria reavaliado, mas isso não aconteceu
Não espero que muita gente faça a mesma escolha que eu fiz. Mas funcionou, e funcionou surpreendentemente bem. Se o que você tirou do texto foi apenas “era um projeto grande e complexo”, então o texto não transmitiu bem a mensagem que eu queria passar
Se fosse comigo, eu teria questionado mais a especificação da UI e defendido rodar o Excel por trás. Mas, quando há muitos campos numéricos por todos os lados, é uma UI familiar
Sempre achei interessante este artigo sobre criar uma planilha em 100 linhas de F#: https://tomasp.net/blog/2018/write-your-own-excel/ Expandir aquilo para o conjunto de recursos necessário aqui parece administrável
No fim, criaram uma cópia caseira do “Excel” como UI para o modelo, porque “as equipes das cidades só sabem usar Excel”
Eu teria feito o contrário. Conectaria o Excel aos dados exportados pelo modelo e deixaria as equipes das cidades continuarem usando o Excel de verdade. Parece que é assim que a maioria das equipes financeiras faz
Para quem tiver curiosidade, a documentação sobre referências circulares no Excel: https://support.microsoft.com/en-us/office/remove-or-allow-a...
Se você não está acostumado a cálculos iterativos, provavelmente não vai querer manter referências circulares. É possível ativar o cálculo iterativo, mas é preciso definir quantas vezes as fórmulas serão recalculadas. Se você ativar o cálculo iterativo sem alterar o número máximo de iterações ou a variação máxima, o Excel interromperá o cálculo após 100 iterações ou quando todas as mudanças de valores nas referências circulares ficarem abaixo de 0,001 entre uma iteração e outra, o que ocorrer primeiro. Ainda assim, é possível controlar o número máximo de iterações e a variação aceitável
Fico me perguntando se o autor veria essa situação de forma diferente se a Uber ou a Box tivessem reivindicado aquele código como delas. Mesmo que o código nunca tenha realizado seu verdadeiro potencial, o fato de pelo menos o mundo inteiro poder vê-lo e reconhecê-lo deve trazer uma certa catarse
Quando eu era estagiário, cheguei a criar uma linguagem de programação inteira. Ela tinha avaliação preguiçosa e coleta de lixo, além de esquisitices específicas da aplicação, como endereços MAC sem aspas serem uma sintaxe válida
Não havia nada como bytecode ou JIT; o interpretador percorria a árvore sintática e fazia push/pop de valores em uma pilha, mas era rápido o suficiente para o que fazíamos. O interpretador foi escrito em ANSI C puro, e o Valgrind também ficava bem satisfeito
Pode ter sido completamente esquecido, ou pode ter virado peça central da infraestrutura técnica daquela empresa. O código nunca saiu do laboratório air-gapped onde eu o escrevi, então não tenho como saber. Três anos atrás, quando eu tinha acabado de sair da faculdade, aquilo era de longe o “software realmente útil” mais legal que eu já tinha escrito, e ainda hoje está entre os primeiros. Às vezes fico pensando no que terá acontecido com ele
O autor parece achar, equivocadamente, que ter perguntado a um gerente intermediário, ou até a um executivo sênior, “vocês querem isso?”, e o gerente ter respondido “não”, vincula legalmente a empresa
A frase “é fácil tratar um código particularmente engenhoso ou elegante como uma obra-prima. E, de fato, ele pode ser um belo objeto decorativo. Mas nós, engenheiros, não estamos no negócio de criar belos objetos decorativos; estamos no negócio de gerar resultados” me marcou
Dito isso, como qualquer pessoa que já viu meu código sabe, eu gosto que meu código e o que ele faz também sejam bem bonitos. Normalmente escrevo código que eu mesmo vou manter, então ele precisa continuar compreensível quando eu olhar para ele daqui a um ano
Estou na fase final de um projeto que não vou apresentar aqui agora e pelo qual nem pretendo levar muito crédito, mas é uma coisa realmente incrível. O motivo de ele ter ficado assim é que ninguém está pagando por ele, e ninguém vai ganhar dinheiro com ele
O dinheiro tanto estraga tudo quanto, ao mesmo tempo, torna tudo possível
Um texto realmente excelente do ponto de vista da antiga equipe de BI da Uber. Eu estava na equipe do Vertica naquela época, e a quantidade de esforço dedicada a incentivos era de deixar a cabeça zonza. Perder milhões de dólares por dia em downtime, funcionalidades de produto e largura de banda de engenharia era um tema comum
Especialmente na época da Uber China, teria sido muito natural um diretor pedir exatamente uma planilha como UI. Eu mesmo carregava pessoalmente no Vertica preços de FX vindos de uma planilha que chegava por e-mail à equipe todo mês. Como não havia largura de banda para inverter o fluxo de controle com coleta automática, esse processo permaneceu por mais de um ano
A frase “até hoje, nunca vi nada tão bem projetado quanto o sistema interno de aplicações da Uber. Do início até rodar um Hello World com CI/CD completo em um subdomínio *.uberinternal.com, levava menos de 30 minutos” aqueceu um pouco meu coração
Eu estava envolvido em tudo isso na Uber naquela época