O usuário não se importa — mas você deveria se importar

• O usuário se importa mais com o produto funcionar do que com as propriedades intrínsecas do código em si, mas código ruim tem impactos secundários diretos em desempenho, bugs e velocidade de desenvolvimento
• A frase “o usuário não se importa com a stack tecnológica nem com testes” pode estar superficialmente correta, mas quanto menor a qualidade do código, mais corrigir bugs e adicionar funcionalidades se torna difícil e lento
• Assim como nas analogias de inspeção de pontes, piloto bêbado e fundação instável de prédios, mesmo que o usuário não veja o processo em si, o resultado afeta segurança e confiabilidade
• Empresas como AirBnB, OpenAI e Meta podem empurrar esse tipo de problema adiante graças ao domínio de mercado, enorme apoio de VC e legalidade questionável, mas nem toda empresa está nessa posição
• O sucesso de software é resultado da ação conjunta de diversos interesses e pontos de vista, de vendas técnicas e stack tecnológica até experiência do usuário e identificadores únicos

---

Clichês recorrentes e seus limites

• Na indústria de software, repetem-se frases como “o cliente não se importa com testes, só quer que o produto funcione”, “o usuário não se importa com a stack tecnológica”, “elegância de engenharia não é o mesmo que valor de mercado” e “o usuário não se importa se foi IA ou uma pessoa que escreveu, nem com qual framework foi usado; só quer que o produto funcione”
• Todas essas frases são variações do mesmo tema: “o cliente não se importa com isso”, apresentadas como um tipo de pragmatismo que encara a realidade de frente
• Quando a mesma lógica é aplicada a outras áreas, a superficialidade do problema fica evidente
  • Dizer que quem usa a estrada não se importa com a inspeção final da ponte, apenas com ela sustentar o carro
  • Dizer que o passageiro não se importa se o piloto bebeu, apenas com o avião chegar no horário
  • Dizer que o trabalhador de escritório não se importa com a estabilidade da fundação de um prédio alto, apenas com ganhar dinheiro
• Essas analogias são superficialmente verdadeiras, mas ignoram impactos secundários evidentes
• É verdade que o cliente não se interessa pelas propriedades intrínsecas do código de computador, mas a qualidade do código afeta desempenho, presença de bugs, tempo para corrigir bugs e tempo para adicionar funcionalidades
• Quanto pior o código, mais difícil e mais lento fica resolver esses problemas
• Aponta-se que empresas como AirBnB, OpenAI e Meta conseguem empurrar essas preocupações adiante com enorme domínio de mercado, grande apoio de VC e legalidade questionável
• A conclusão é que, se a empresa não é desse tipo, é difícil encobrir o problema da mesma maneira

A persistência da ‘sabedoria popular’ e os vários interesses do software

• A persistência da sabedoria popular

  • A ideia de que apenas os efeitos de primeira ordem importam existe no software como uma crença popular muito difundida
  • As pessoas tendem a desvalorizar ou minimizar aquilo em que não são boas
  • Se percebem que não têm capacidade de produzir bom código, passam facilmente a adotar a visão de que bom código não só não importa, como também de que as pessoas capazes de produzi-lo é que são o problema
  • Nessa visão, quem impede um lançamento por causa de coisas com as quais o cliente não se importa passa a ser tratado como o problema
  • Essa atitude funciona como um mecanismo de defesa do ego para evitar as próprias fraquezas e externalizar a responsabilidade para os outros

• Vivemos em sociedade

  • Trabalho sério com software é uma mistura de interesses e perspectivas diferentes
  • De vendas técnicas à stack tecnológica, de experiência do usuário a identificadores únicos, muitos elementos entram em um esforço de software
  • Todos esses elementos contribuem para o sucesso ou o fracasso

[GN⁺]

Opiniões no Lobste.rs

• Frases assim podem ser boas ou ruins tanto na forma como são transmitidas quanto na forma como são lidas
  Por exemplo, a frase “o cliente não se importa nem um pouco com testes. Ele se importa se o produto funciona” pode ser lida não como “libere bugs”, mas como um foco em fazer o produto realmente funcionar em vez de em uma ideologia de testes específica
  Como testes são um dos meios de fazer o código funcionar, se a cobertura de testes for alta e tudo passar, mas o produto não funcionar, isso é fracasso; se o produto funcionar bem por outros meios além de testes, tudo bem; e mesmo sem seguir uma doutrina formal, se você encontrar bem os bugs, isso também pode ser uma interpretação aceitável
  Além disso, do ponto de vista do usuário e do negócio, “o produto/recurso não existir” também pode ser um bug, então corrigir bugs existentes e lançar recursos nem sempre são coisas separadas de forma tão limpa
  Dito isso, na prática também já ouvi esse tipo de frase ser usado com o sentido de “faça nas coxas e lance lixo”

  • Sobre o ponto de que “do ponto de vista do usuário e do negócio, o produto/recurso não existir também é um bug”, há uma parte que eu, como autor, não tratei explicitamente
    Rejeito completamente a ideia de que programação ruim seja “prática”, mesmo olhando em escala de meses
    Criar novos recursos em uma base de código com design ruim e testes insuficientes é lento e caro
  • Também há muitos engenheiros que acham que “quanto mais testes unitários, melhor” ou passam dias otimizando código que nem é gargalo, então, nesses casos, as interpretações acima são bem apropriadas
    Desenvolvedores precisam estar conscientes de se estão gastando tempo onde valor é criado, e idealmente a gestão também deveria entender por que esse trabalho está sendo feito
    Quando falta entendimento e a estrutura de incentivos é ruim, o resultado acaba sendo “fazer nas coxas e lançar lixo”

• Sinceramente, muitas vezes quem diz esse tipo de coisa parece ser justamente alguém que também não se importa muito com o usuário
  Para fazer o usuário receber um produto que funcione, é preciso haver mecanismos no processo de desenvolvimento que aumentem essa probabilidade, e isso eu já tinha dito em um comentário de alguns dias atrás
  Esse tipo de sentimento aparece com frequência quando não há uma forma adequada de o usuário dar feedback sobre o produto, e também não existem métricas reais de uso
  Há muitos cenários de falha que afetam o usuário mesmo que ele não os veja imediatamente ou não se importe com eles na hora
  Segurança é um exemplo clássico: até que os dados apareçam em um vazamento online, o usuário pode não se importar com o fato de o sistema “não ser seguro”; e desempenho também pode não parecer um problema até ele descobrir que poderia ser muito melhor

  • É difícil explicar esse tipo de tema para um público geral
    Em qualquer processo de melhoria, é difícil obter um bom resultado escolhendo só um elemento para otimizar, mas para fazer a discussão avançar muitas vezes não há alternativa
    Por isso, ajuda ajustar a discussão alinhando o caminho do feedback para onde realmente está o problema visível
    Vejo textos assim como uma tentativa de fazer as pessoas pensarem em elementos que afetam o sucesso de projetos de software, mas que parecem mutuamente excludentes
    Colocar em palavras e defender coisas que só pessoas com senso técnico costumam perceber tem valor, mas parece que muitos profissionais de tecnologia não conseguem equilibrar esse trabalho invisível nem persuadir de forma eficaz, e eu também continuo praticando essa parte

• Se importar com a parte interna é importante e, na prática, isso também beneficia o usuário

• Gosto dessa perspectiva
  Não quero ir para o extremo oposto de overengineering, mas queria que saíssemos da mentalidade de “mover rápido e quebrar coisas”
  Pela minha experiência, no mundo do desenvolvimento web isso é quase uma epidemia
  Tomara que a enxurrada de software de baixa qualidade possibilitada por LLMs acabe fazendo os usuários recompensarem software confiável
  Estou cada vez mais virando um desenvolvedor grug brain, então não sei se isso é um sentimento amplamente compartilhado, mas cansei de “vamos adicionar só mais um recurso”
  Muitas vezes cometemos o erro de medir o custo do software apenas pela data de lançamento, e quase não incluímos o custo de manutenção ao longo de toda a sua vida útil
  Dizem “não é difícil, leva menos de uma semana!”, mas não falam do tempo que vai entrar todos os anos em manutenção, correções, extensões, atualizações, integrações e documentação: de 2 a 4 semanas

• Eu costumo dizer algo parecido
  “O usuário final não se importa se o software tem 100% de cobertura de testes ou se foi escrito 100% em assembly sem documentação com rótulos como lbl0. Ele se importa com correção, desempenho e experiência do usuário”
  Mas a engenharia de software é justamente o que ajuda a chegar a esses objetivos com mais facilidade e a manter a qualidade em um bom nível
  O problema é que esse caminho também pode levar a culto de carga e a overengineering, e eu certamente também sou culpado disso
  Ainda assim, no fim das contas é preciso entregar valor real ao usuário

• Como em Boeing e Airbus, existe um resultado ótimo demonstrável
  O ponto principal não é por que as aeronaves das duas empresas parecem tão parecidas, nem quem projetou primeiro ou quem copiou quem
  Ninguém copiou ninguém; simplesmente os melhores engenheiros do mundo, em equipes diferentes, projetando sob as mesmas restrições, fazem com que qualquer projeto fora disso seja, por definição, inferior
  É preciso estar na fronteira de Pareto, senão você é engolido
  No nosso campo também existe um ponto ótimo em algum lugar; a questão é se temos as ferramentas, o orçamento e as pessoas certas para chegar lá, e se há usuários suficientes para descobrir se realmente chegamos lá