Os usuários não se importam — mas você deveria se importar
(lewiscampbell.tech)- Os usuários se importam mais com o produto funcionando do que com as propriedades intrínsecas do código em si, mas código ruim tem efeitos indiretos diretos sobre desempenho, bugs e velocidade de desenvolvimento
- A frase “os usuários não se importam com a stack tecnológica nem com testes” pode até parecer superficialmente correta, mas quanto pior a qualidade do código, mais difícil e lento fica corrigir bugs e adicionar funcionalidades
- Assim como nas analogias de inspeção de pontes, pilotos bêbados e fundações instáveis de prédios, mesmo que o usuário não veja o processo em si, o resultado afeta segurança e confiança
- A popularidade desse tipo de lugar-comum pode ter como pano de fundo um mecanismo de defesa do ego que leva a desvalorizar aquilo em que a própria pessoa não é boa
- Trabalho sério com software é uma mistura de diferentes interesses e perspectivas, e todos contribuem para o sucesso ou fracasso; por isso, qualidade de código não deve ser tratada com descaso
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”
- “O usuário não se importa se foi escrito por IA ou por uma pessoa, 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”
- Elas assumem uma postura como se um pragmático experiente estivesse revelando a dura verdade do mundo para pessoas idealistas ou míopes
- Mas isso é tudo bobagem (horseshit), e
quando a mesma lógica é aplicada a outras áreas, as falhas ficam evidentes- Quem usa a estrada não se importa se a ponte passou pela inspeção final; só quer que ela sustente o carro
- O passageiro não se importa se o piloto está bêbado; só quer que o avião chegue no horário
- O trabalhador de escritório não se importa se a fundação de um arranha-céu é estável; só quer ganhar dinheiro
- Essas analogias parecem corretas na superfície, mas ignoram efeitos indiretos óbvios (downstream effects)
Efeitos indiretos ignorados
- É 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, existência de bugs, tempo para corrigir bugs e tempo para adicionar funcionalidades
- Quanto pior o código, mais difícil e demorado fica resolver esses problemas
- Empresas como AirBnB, OpenAI e Meta conseguem empurrar essas preocupações para debaixo do tapete graças ao enorme domínio de mercado, apoio massivo de VCs e legalidade questionável
mas, se você não é uma empresa desse tipo, fica muito mais difícil encobrir os problemas da mesma forma
A persistência da “sabedoria popular” e os múltiplos interesses do software
-
A persistência da sabedoria popular (The Persistence of Folk Wisdom)
- A ideia de que só os efeitos de primeira ordem importam se tornou uma sabedoria popular muito difundida no software
- As pessoas tendem a desvalorizar ou minimizar aquilo em que não são boas
- Quando alguém percebe que não tem capacidade de produzir bom código, tende a adotar a visão de que código bom não só não é importante, como também de que as pessoas capazes de produzir bom código é que são o problema
- Nessa perspectiva, quem impede o lançamento por causa de coisas com as quais o cliente não se importa passa a ser tratado como problema
- Essa atitude funciona como um mecanismo de defesa do ego (ego defence mechanism) para evitar as próprias fraquezas e transferir a responsabilidade para os outros
-
Vivemos em uma sociedade (We Live in a Society)
- Trabalho sério com software é uma mistura de interesses e perspectivas diferentes
- De vendas técnicas (tech sales) à stack tecnológica (tech stack), de experiência do usuário (UX) a identificadores únicos (unique identifiers), muitos elementos entram em um esforço de software
- Todos esses elementos contribuem para o sucesso ou fracasso
1 comentários
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”
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
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
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á