Nenhum cão foi ferido durante a criação deste app

 (shmck.substack.com)
1 pontos por GN⁺ 2023-11-04 | 1 comentários | Compartilhar no WhatsApp
  • Em 2016, a função de upload de fotos com localização de um app mobile em React Native falhava apenas no beta do Android, enquanto o problema não podia ser reproduzido no Android local nem no iOS, e isso foi investigado por uma semana
  • O beta do Android não fornecia feedback de erro mesmo quando o upload da imagem falhava, e cada novo build enviado para a Play Store levava cerca de 1 hora, o que tornava lenta a validação das hipóteses
  • Em comparação com casos de sistemas embarcados, hardware, química e veterinária, fica claro que a depuração de software é muito mais rápida e oferece bem mais observabilidade
  • A causa real foi uma diferença de uma única letra ao escrever o tipo MIME da imagem como "jpg"; mesmo que a extensão do arquivo fosse .jpg, o tipo MIME deveria ser "jpeg"
  • Um ambiente de desenvolvimento onde logs, observação em tempo real, depurador e experimentos iterativos podem ser usados de forma barata é quase um grande privilégio quando comparado aos ciclos de feedback de outras profissões

Upload de fotos que falhava apenas no beta do Android

  • A funcionalidade de geolocated photos de um app mobile em React Native parecia pronta para ser lançada na segunda-feira, mas, após a distribuição do beta para Android, as imagens não eram enviadas
  • Nos testes locais no Android e no beta do iOS tudo funcionava normalmente, então a causa da falha não ficou evidente de imediato
  • Mesmo após subir novamente uma versão com tratamento de erros melhorado, a falha no upload continuava acontecendo sem nenhum feedback
  • Levar um novo ciclo para a Play Store consumia cerca de 1 hora, e era preciso esperar o build ser distribuído enquanto a próxima hipótese era preparada

Ciclos de feedback mais longos em outras profissões

  • Um engenheiro de sistemas embarcados passou por uma situação em que, após implantar uma atualização de firmware em equipamentos remotos, os nós deixaram de responder
    • Para identificar a causa, era necessário recolher os equipamentos e analisá-los
    • Em alguns casos, descobrir o que deu errado levava meses
  • Um engenheiro de hardware observa que um novo hardware implantado remotamente pode revelar falhas de projeto só depois de resistir a várias estações do ano
    • Equipamentos antigos são recebidos pelo correio para que correções sejam incorporadas à próxima geração do produto
    • Houve um caso em que foram adicionadas aberturas de ventilação para reduzir o calor, mas os furos eram grandes o bastante para vespas fazerem ninhos, o que virou um bug ainda pior
    • Testes de laboratório são possíveis, mas a validação final acaba acontecendo em campo

A forma de aceitar o fracasso

  • O CEO relembra que, quando era químico preparando sua tese de doutorado, conduziu experimentos com uma grande verba de pesquisa para reagentes caros, mas semanas depois os resultados pareceram ter fracassado por erro experimental
  • Ele não conseguiu descobrir o que tinha dado errado e também não soube responder à pergunta sobre o que faria diferente para não repetir o mesmo erro
  • Ainda assim, recebeu uma segunda verba, e essa experiência se tornou um exemplo de liderança empática que ajuda alguém a se reerguer após um fracasso

O caso da veterinária mostrou riscos mais altos

  • Uma amiga veterinária atendeu um cão idoso e doente e recomendou um raio-X ao tutor, mas ele recusou por causa do custo
  • Sem o raio-X, o melhor que podia ser feito era apalpar externamente o abdômen do cão, e um objeto grande foi sentido
  • O que foi removido por cirurgia era um sabugo de milho, mas, sem raio-X, não havia como ter certeza de que aquilo era todo o problema
  • No dia seguinte, o cão morreu, e, ao contrário de um problema no lançamento de um app mobile, o fracasso em outras profissões pode envolver literalmente vida ou morte

O privilégio de um bug de uma letra e das ferramentas de depuração

  • Na sexta-feira de manhã, foi percebida uma inconsistência entre a documentação do Android e a base de código, e a causa do problema que durou uma semana era um único caractere
  • O tipo MIME da imagem estava definido como "jpg", mas na verdade deveria ser "jpeg", enquanto o arquivo era salvo como .jpg
  • Desenvolvedores de software conseguem olhar profundamente para processos complexos, monitorar o comportamento em tempo real, registrar logs e pausar a execução com um depurador para inspecionar tudo
  • Essa capacidade é barata e rápida, e permite repetir experimentos várias vezes por dia com apenas alguns cliques
  • Software também pode ser tão importante e impactante quanto o trabalho de outras profissões, mas os desenvolvedores trabalham em um ambiente em que vale a pena agradecer pelas ferramentas de depuração que têm hoje

Leituras relacionadas

1 comentários

 
GN⁺ 2023-11-04
Opiniões do Hacker News

  • É uma história quase alegórica sobre como a engenharia de software difere de outras profissões — brincando, das profissões “de verdade”
    Também gosto de uma versão mais curta e espirituosa: um engenheiro de software, um engenheiro de hardware e um chefe de departamento estavam indo para uma reunião na Suíça quando, numa estrada íngreme de montanha, os freios falharam, o carro desceu batendo no guard-rail e, por milagre, parou
    O chefe de departamento propõe fazer uma reunião para definir visão, missão e objetivos, e resolver o problema central com melhoria contínua; o engenheiro de hardware sugere desmontar e consertar os freios com um canivete suíço
    O engenheiro de software diz: “Antes de fazer qualquer coisa, vamos empurrar o carro de volta para cima e ver se reproduz de novo”

    • A grande vantagem da engenharia de software é lidar com abstrações. É parecido com construir castelos nas nuvens: dá para remodelar tudo, até os alicerces
      Ao mesmo tempo, a grande desvantagem da engenharia de software também é lidar com abstrações. Até os alicerces se movem
      http://thecodelesscode.com/case/154
    • A moral dessa história é simplesmente que o engenheiro de hardware está certo?
    • Engenheiro mecânico, no caso
    • E se, ao apertar “executar de novo”, o carro reaparecesse milagrosamente no alto da ladeira, a mesma coisa se repetisse e, no instante em que os freios falhassem, fosse possível parar o tempo, desmontar todas as peças do carro e ver exatamente onde está o problema em tempo real, em câmera lenta e em reverso?
      Ter essa capacidade não significa que o engenheiro de software seja ridículo ou irrealista
      A engenharia no espaço digital oferece uma capacidade de depuração que, no mundo físico, é quase milagrosa. Se você quiser criar 10 cópias do mesmo objeto e testá-las de 10 maneiras diferentes, é literalmente CTRL+C, CTRL+V. Eu queria ver um mecânico fazendo isso
    • Só os freios não funcionam; o motor está normal. Por que empurrar o carro de volta para o alto da ladeira?
    • Eu fecharia todas as janelas e reiniciaria

  • Estou realmente cansado das reclamações de que engenheiros de software não são “engenheiros de verdade” e de que tudo se resolveria se fizéssemos mais grandes reuniões de projeto antecipado e um planejamento gigantesco
    Outras áreas da engenharia trabalham assim não porque sejam muito mais profissionais que nós, nem porque esse método seja melhor, mas porque não têm outro jeito. Depois de terminar um hotel, ninguém percebe que o teto precisa ser 6 polegadas mais alto, derruba tudo e constrói de novo
    Se eles pudessem executar ceilingHeight += 6, clicar em “Rebuild”, ver o hotel reconstruído enquanto testes unitários automáticos verificam até acessibilidade, tudo por um custo total de US$ 2,82, é claro que também fariam assim
    Precisamos largar esse complexo de inferioridade. Fazemos engenharia com ferramentas que engenheiros civis e mecânicos do mundo real nem conseguem sonhar, e é natural que o processo seja bem diferente por causa disso
    Claro que às vezes não aplicamos processo suficiente ao problema. Mas, se você acha que isso é um problema exclusivo da programação, eu receitaria algumas horas assistindo a https://www.imdb.com/title/tt4788946/

    • Acho que você perdeu o ponto principal. Planejamento antecipado e reuniões não são a essência; eles são consequência dos critérios anteriores. Engenharia é resolver problemas práticos de forma científica, onde segurança, repetibilidade e compreensão dos princípios da solução são inegociáveis; onde quem resolve é qualificado como engenheiro em termos de ética e rigor científico; e onde, justamente por essa qualificação, assume responsabilidade inescapável quando uma solução aprovada falha
      Não é uma questão de superioridade: se faltar qualquer um desses critérios, você não está fazendo engenharia. Pela minha experiência, a maior parte do desenvolvimento de software não tem nenhum dos quatro. Isso não é necessariamente ruim, mas a maior parte do desenvolvimento de software não é engenharia
      Isso não quer dizer de forma alguma que engenharia seja superior a desenvolvimento
    • Concordo totalmente. Meios diferentes têm processos e técnicas otimizados para cada um
      É como a diferença entre esculpir em argila e em mármore. Se você erra na argila, basta mexer de novo rapidamente; se remove do mármore uma parte que não devia, precisa encomendar um novo bloco de mármore
      Trazer o modo de esculpir mármore para o mundo da argila só faz de você um escultor de argila péssimo — ou, no mínimo, muito ineficiente
      Também não faz muito sentido disputar qual escultura, em argila ou em mármore, tem mais valor. Ambas têm seu lugar na sociedade
    • Totalmente à parte, mas um dos motivos pelos quais impressão 3D é ótima é que ela dá a experiência mais próxima de ceilingHeight += 6 no mundo real
      Ainda hoje modelei e imprimi uma peça, e percebi que uma parte ficaria melhor cerca de 1 mm mais grossa. Trinta segundos depois, a versão 2 já estava indo para a impressora
      É realmente incrível. Mal posso esperar para que algo assim se torne tão popular quanto impressoras de papel
    • Acho que as pessoas que pensam que engenharia de software não é engenharia de verdade ficariam surpresas ao descobrir que uma parte considerável da engenharia “de verdade” é simplesmente colocar números em software
    • Olhando para aviões e jatos projetados antes do CAD, dá para ver que projetos de engenharia também podiam ser bastante ajustados no local. Eram feitos para encaixar perfeitamente, com o know-how gravado na cabeça de quem os construiu e de quem os consertou
      https://www.youtube.com/watch?v=NPVT2lvMvOk

  • Várias vezes ao longo da carreira, algo dava erro, mas de forma completamente silenciosa, e todo mundo ficava travado. Não havia saída de erro, nem nada
    Em muitos desses casos, a causa era uma biblioteca de terceiros de baixo nível fazendo catch (e) {}. O primeiro caso que enfrentei no começo foi uma boa lição, e hoje não deixo nenhum erro passar como se fosse normal. No mínimo, registro em log
    O software que você está criando agora pode ser usado daqui a 5 anos em um ambiente que você jamais imaginou

    • “Esta função é tão óbvia para todo mundo da equipe que não precisa de comentário”
      30 anos depois:
      /* X systems I modul body I 14.09.1990 */
      void xxvcda(int *addr, int sizeof)
    • É bem isso. No código que estou olhando agora, alguém que passou por aqui por pouco tempo antes está engolindo exceções de uma biblioteca inferior e, em vez disso, lançando uma exceção completamente inútil
      A pessoa nem conhecia o recurso da linguagem que permite levantar uma nova exceção a partir da anterior para preservar o contexto do stack trace. Coisa divertida. Pelo menos não é o código do meu trabalho principal — embora o trabalho principal também tenha suas próprias diversões
    • Tive algo parecido recentemente com DRF e JWT. Por causa de um problema intermitente de timing, o JWT não era válido e não era possível fazer login
      O DRF engolia o erro de validação e retornava só um erro genérico, então não havia pista nenhuma; no fim, tive que ir descendo manualmente e adicionando logs para descobrir o que estava acontecendo

  • Um amigo físico citava com frequência a frase de Rutherford: “toda ciência ou é física, ou é coleção de selos”
    O que ele queria dizer era que a física, ao contrário da matemática ou da ciência da computação, tem uma forma de ser validada pela realidade física
    A área dele era campos magnéticos extremos, e os experimentos consistiam em construir enormes bobinas de cobre, passar corrente suficiente para derretê-las e depois detonar explosivos ao redor da bobina para tornar, por um instante muito breve, o campo magnético central o mais forte já produzido pela humanidade, enquanto cobre líquido a milhares de graus espirrava e todo o aparato era destruído
    Nesse ambiente de trabalho, erros ou cálculos equivocados significam que pessoas podem morrer de forma muito rápida e terrível. Por isso ele não concordava quando doutorandos em matemática, cujo maior dano possível era ficar com pó de giz no suéter, chamavam a si mesmos de cientistas

    • É uma interpretação bem peculiar dessa citação. Segundo vários livros, o significado é que a ciência ou é matemática e quantitativa, ou então é descritiva
      Em outras palavras, ou tenta entender a dinâmica do objeto de estudo, ou se limita a reunir fatos interessantes e dar nomes aos objetos de interesse
    • Geradores de compressão de fluxo magnético bombeados por explosivos[1] são divertidos
      Para quem tem interesse em uma carreira de supervilão, mas não sabe por onde começar: é assim que se faz um EMP de verdade
      [1] https://en.m.wikipedia.org/wiki/Explosively_pumped_flux_comp...
    • Eu me perguntava por que Dijkstra era tão arrogante, até descobrir que ele estudou física teórica, aí entendi
    • Não vejo muito matemáticos se chamando de cientistas. Pelo contrário: em geral eles se gabam de não serem cientistas e de não estarem limitados por trivialidades da realidade
    • Como bom físico, interpretou mal essa citação

  • Depois de algo assim, sempre fico desejando que houvesse uma ação corretiva upstream. Com logging e relato de erros adequados, não teria levado uma semana para corrigir
    A biblioteca que recebeu o tipo MIME incorreto image/jpg deveria ter lançado uma exceção, travado ou, no mínimo, registrado isso em logs de forma bem visível. Fico curioso se o autor original abriu um bug nessa biblioteca

    • Perto do fim do texto, fiquei me perguntando em que tipo de ambiente o Shawn trabalhava para o diagnóstico ter demorado tanto
      Ele tinha acesso para confirmar ou descartar se uploads de imagem estavam realmente chegando ao servidor? Por que o upload funcionava no ambiente de teste, mas não na versão lançada do app? O que havia de diferente no ambiente de teste?
      Em tese, Shawn deveria ter acesso suficiente para responder bem rapidamente a “o upload foi bem-sucedido, então por que ele não aparece?”, seja operando o servidor diretamente, seja pedindo ajuda a alguém que pudesse diagnosticar por que o upload falhava silenciosamente
      Na minha opinião, mais do que “o tipo MIME da imagem era jpg e deveria ser jpeg”, a lição muito mais importante é por que funcionava em teste e não em produção. Mais do que o bug em si, o grande ponto é por que o ambiente dificultou encontrar o bug
      No meu caso, um app de desktop se comportava muito mal, mas o erro não aparecia nos logs. Só alguns dias depois descobri que os handles de arquivo tinham se esgotado e que o log4net também não consegue registrar logs se não conseguir obter um handle de arquivo. A solução para reverter uma pequena correção de bug era simples, mas a correção real foi customizar o log4net para manter o arquivo de log sempre aberto. Assim, mesmo que o app esgote os handles de arquivo, o erro ainda é registrado
    • O parágrafo relacionado do texto me incomoda um pouco: “Reenviei uma versão com tratamento de erros melhorado, mas o upload de imagens falhava sem nenhum feedback. Normalmente, o código grita erros em letras vermelhas, e o silêncio é o objetivo. Aqui, o silêncio era o problema.”
      O silêncio não é o objetivo. Muitos desenvolvedores demais acham que o objetivo é o silêncio, mas o objetivo real é a correção. Se não há erro, deve ficar quieto; mas, se há um erro que afeta o usuário, deve haver uma grande caixa de alerta vermelha
      Acho que desenvolvedores precisam aprender a gostar de mensagens de erro. Uma mensagem de erro bem escrita revela rapidamente a causa e economiza muito tempo de todo mundo
      Se esse desenvolvedor aprendeu a mostrar mensagens de erro com mais frequência daqui em diante, isso é um resultado muito bom

  • Isso me lembra um ex-colega que dizia com frequência: “não é como se estivéssemos construindo um sistema de controle de tráfego aéreo”. Ele queria dizer que um erro não colocaria vidas em risco
    Na época estávamos fazendo jogos, mas a frase também se aplicava a quase todos os apps CRUD que escrevi
    Separadamente, costumo perguntar a outros líderes técnicos seniores, especialmente diretores, VPs e CTOs: “qual foi o erro mais caro que você já cometeu?”. Se você é engenheiro júnior, vale muito a pena fazer isso algum dia
    Muitos líderes técnicos de alto escalão têm histórias na faixa de 100 mil a 1 milhão de dólares. Já vi gente que queimou milhões de dólares em um projeto e foi promovida logo depois. É importante entender por que isso é possível e até por que pode ser algo positivo

    • Discordo. Uma falha pode não resultar em morte em uma bola de fogo, mas ainda assim pode causar danos. Pequenos danos também se acumulam quando ganham escala
      A frustração com um jogo cheio de bugs pode levar a agressividade no trânsito ou a discussões aos gritos na vida real. Há pessoas que se suicidaram porque um computador enviou uma cobrança incorreta. Há empresas que quebraram porque um software perdeu dados valiosos
      Pessoas já foram assassinadas por causa de apps de mídia social aparentemente triviais, e incitações a massacres já foram organizadas no Twitter. Também houve pessoas perseguidas e agredidas por informações vazadas pelo Pokemon Go
      Software tem poder real. Se não tivesse, nem haveria motivo para escrevê-lo
    • A atitude de “não é como se estivéssemos construindo um sistema de controle de tráfego aéreo” também me incomoda
      Já trabalhei em software que podia perder dados valiosos, e agora trabalho em software que, se falhar, pode causar alagamentos
      As pessoas deveriam ter um pouco mais de orgulho do próprio trabalho

  • Como engenheiro de software, eu gostava bastante de depurar. Porque isso me fazia usar habilidades e uma forma de pensar diferentes das usadas para criar e implementar um design
    Claro que isso não quer dizer que depurar não cause estresse. Quando eu desenvolvia software para o comutador telefônico 5ESS da AT&T, houve uma demo, e no laboratório de testes havia apenas uma linha telefônica configurada para o nosso recurso
    Por mais que tentássemos, o software não funcionava e, convencido de que o software estava certo, fiquei estressado verificando tudo o que era possível. No fim, pedi ao técnico do laboratório para verificar a linha, e a única linha configurada por acaso estava desconectada. Era um problema idiota de hardware

    • Comigo é igual. Sempre gostei especialmente do desafio da depuração em sistemas complexos
    • Depurar é divertido quando há ferramentas, mas não é tão bom quando, por consequência das escolhas feitas, tudo está distante demais, seja metafórica ou literalmente
      Depurar sistemas distribuídos na nuvem é exponencialmente mais horrível do que quando dá para subir todos os serviços localmente, e mesmo esse sistema distribuído local é muito pior do que poder depurar o problema dentro de um único programa
      Um depurador de verdade também torna a depuração muito melhor. Nunca entendi quem insiste em usar só printf debugging ou só um depurador de verdade. Usar os dois traz um ganho enorme. Um bom tracing também merece destaque aqui, porque, quando possível, é muito melhor do que printf debugging
      No começo da programação, eu associava muitas emoções desnecessárias ao estado de não saber por que algo acontecia, mas aos poucos passei a aceitar o ciclo de “pera, por que isso está assim? não sei… ah, espera… uau, o motivo de isso não funcionar faz todo sentido!”, e também internalizei que é gostoso chegar até o fim
      Hoje, o próprio estado de não saber só é estragado pelas expectativas e ações de outras pessoas. Com o tempo, aprendi que é preciso administrar de forma bem firme escolhas de linguagem, escolhas de arquitetura etc. para tornar esse processo fácil e rápido
      Neste ponto da carreira, é muito mais fácil convencer de antemão que AWS Lambda é uma escolha ruim em desempenho, custo total, capacidade de depuração e velocidade de desenvolvimento do que convencer depois que há bons motivos para “por que está demorando tanto para corrigir aquele único problema”

  • Ri no final. Ainda ontem, resolvi um problema que atormentava a empresa havia 3 anos, e no nosso caso a causa era a letra A
    Nos últimos 3 anos, alguém vinha fazendo uma correção manual de inserir e remover dados, e isso virou parte do trabalho dele. Ele até tinha colocado um evento recorrente no calendário para a limpeza periódica. Milhões de clientes dependiam dessa única pessoa para que o plano de dados correto fosse aplicado à linha de celular deles
    Dá para imaginar a bagunça que aconteceria se ele esquecesse ou saísse de férias
    No fim, a causa era if $line->status == STATUS_ACTIVE: um era Active, o outro era active. Nenhum cachorro se machucou, mas uma quantia incalculável de dinheiro desapareceu ao longo de vários anos

    • Se fosse um caso jurídico, a piada seria: “O que você fez? Você acabou de resolver o caso que teria pagado a faculdade de direito da minha família inteira!”
      Aquele pobre sujeito deixou de ser indispensável. Meio de brincadeira. Software serve para tornar o trabalho mais eficiente, mas também costumo observar as motivações humanas
    • Já vi casos complicados em que caracteres invisíveis, como espaços ou quebras de linha, causavam estrago
      Sofri especialmente ao preencher campos HL7 no Mac. Acho que o caractere ’ digitado em um teclado Mac não era compatível com todas as versões do HL7, ou não batia com o destino para o qual o HL7 era repassado
      É uma lembrança antiga, mas a diferença entre palavras como o’clock e o′clock quebrava a distribuição de laudos de radiologia. Isso continuou por anos até ser encontrado
      O HN está exibindo o ’ de forma diferente do que eu digitei, mas ainda é o mesmo caractere. É bem engraçado, já que metade do problema era que a diferença não era visível durante a depuração
    • Será que STATUS_ACTIVE estava definido de forma errada em alguma parte do código?
      Sempre existe o risco de alguém “gentilmente” corrigir o erro de digitação referer de HttpHeader::REFERRER para referrer. Mas esse erro está fossilizado no padrão HTTP, então fazer isso quebra completamente o software. Culpa do Phillip Hallam-Baker, da época do CERN

  • A história do ninho de vespas me pareceu bem familiar
    O locador do nosso prédio de escritórios instalou uma interface touchscreen do lado de fora do edifício para que fosse possível ligar para cada recepção e abrir a porta. Fizeram isso porque não havia recepcionista com visão da porta
    O aparelho durou 6 meses antes de começar a apresentar defeitos graves. A causa foi que a interface, que na prática era um grande tablet Android preto, tinha sido instalada na face leste do prédio
    No meio da primavera, ele passou a receber sol suficiente todos os dias para superaquecer, e parte da eletrônica de toque e do hardware da tela foi danificada
    No tipo de software que eu faço, não preciso me preocupar com carga térmica

    • Isso me lembra a história da luz do sol parando trens. Segundo a Southeastern, o serviço em Lewisham, no sudeste de Londres, atrasou por causa do ângulo do “sol baixo de inverno”
      A companhia ferroviária postou no Twitter: “Houve congestionamento severo nos serviços que passam por Lewisham devido a problemas de partida causados pela luz solar intensa”
      Também disseram que o sol baixo de inverno incidia sobre o monitor de partida e impedia o maquinista de vê-lo

  • A mensagem “finalmente resolvi. Era por causa da letra ‘E’” é divertida
    Muitas vezes, os bugs mais simples e menores são justamente os mais difíceis de encontrar. Ainda hoje de manhã perdi uma ou duas horas procurando um erro off-by-one
    A causa era um único index + 1 que esqueci de alterar durante uma refatoração

    • Como se costuma dizer, há dois problemas difíceis em ciência da computação: invalidação de cache, nomeação e erros off-by-one