Tenho uma teoria de que o software deixa as pessoas loucas

A intangibilidade do software e o baixo custo percebido de mudança são apontados como fatores que incentivam redesenho constante, arquiteturas excessivamente complicadas e metodologias passageiras, o que por sua vez cria ambientes caóticos e burnout. Os comentaristas associam essa instabilidade menos ao código em si e mais aos incentivos ligados ao hiper-crescimento, à rotatividade de recursos orientada por analytics e a gestores distantes dos usuários e do esforço de implementação. Muitos defendem ciclos de feedback mais curtos com usuários reais, o uso do próprio produto pela equipe e a resistência a mudanças desnecessárias como formas práticas de restaurar a sanidade e construir sistemas mais simples e confiáveis.

Tangente sobre lavar as mãos e linha de base da “sanidade”

  • A discussão começa com o debate sobre se lavar as mãos com frequência é “louco” hoje em dia.
  • Vários mencionam lavar mais as mãos após a pandemia e se sentirem menos doentes.
  • É citada uma revisão Cochrane sobre intervenções físicas: benefício modesto, mas incerto, da higiene das mãos; baixa adesão enfraquece os resultados; a evidência sobre máscaras também é incerta.
  • Outros lembram debates anteriores no HN de que “mãos sujas” podem ser benéficas.
  • Alguns argumentam que julgar a sanidade por hábitos como esse mostra que o artigo parte de uma premissa frágil.

Desenvolvedores, usuários e estrutura organizacional

  • Muitos argumentam que não é o software em si, mas construí-lo isolado dos usuários que “deixa as pessoas loucas”.
  • O contato direto e regular com clientes (inclusive fazendo suporte de primeiro nível) é visto como algo que dá base e clareza.
  • Quando a comunicação é mediada apenas por gerentes de projeto/produto, os requisitos se distorcem, as prioridades viram política e os devs perdem contato com os problemas reais.
  • Alguns dizem que os próprios devs muitas vezes resistem ao contato com usuários, considerando-o uma distração; outros chamam essa atitude de pouco profissional, mas observam incentivos desalinhados (desempenho atrelado à quantidade de tickets resolvidos).

Analytics vs. usabilidade e decisões de recursos

  • Critica-se a forte dependência de analytics sem contexto.
  • Padrão comum: recursos pouco usados são removidos com base em contagens brutas de uso, ignorando fluxos de trabalho críticos, mas infrequentes, e problemas de descobribilidade.
  • Exemplo: a remoção da opção de “fechar abas à direita” de um navegador, justificada por baixas taxas de clique; comentaristas argumentam que baixa frequência ≠ baixa importância.
  • Às vezes a gestão “fabricava” dados (enterrando recursos primeiro) para justificar cortes.
  • Pesquisa de usabilidade e observar pessoas lutando com interfaces contradizem repetidamente hipóteses derivadas de analytics.

Dogfooding, empatia e seus limites

  • Usar o próprio software é elogiado como uma forma poderosa de evitar a loucura e identificar rapidamente atritos.
  • Isso é creditado por melhor acessibilidade e fluxos de trabalho mais confiáveis e com menos atrito.
  • No entanto, o dogfooding pode induzir a erro quando os desenvolvedores usam o produto de maneiras estreitas e especializadas que não correspondem aos usuários típicos.

Rotatividade tecnológica, complexidade e cultura do setor

  • Vários contrastam pequenas equipes focadas do passado, entregando sistemas críticos, com as equipes grandes de hoje lançando apps CRUD superengenheirados.
  • A rotatividade tecnológica e toolchains inchadas são apontadas como responsáveis por esforço desperdiçado e sobrecarga cognitiva, agravando a “loucura”.
  • Outros argumentam que o verdadeiro motor é dinheiro e hype competitivo: tudo precisa ser uma “plataforma” ou uma “empresa de dados”, então produtos triviais são rebatizados como algo que mudará o mundo.

Natureza do software e expectativas

  • A intangibilidade e maleabilidade do software estimulam mudanças constantes; o custo de mudança é percebido como baixo, então tudo vira urgente.
  • Usuários frequentemente tratam a saída do software como autoritária e confiável; quando aparecem bugs ou atrasos de propagação, eles experimentam ansiedade desproporcional.
  • Alguns veem o software simplesmente como algo que revela o ego humano preexistente, a ilusão e a disfunção corporativa, em vez de causá-los de forma única.

Recepção do artigo

  • Muitos acharam o post identificável e engraçado, capturando disfunções reais do setor.
  • Outros acharam-no divagante, pouco estruturado e longo demais, com uma tese central fraca ou confusa.