Qualidade é difícil de vender em big tech
A qualidade em grandes empresas de tecnologia é vista como cada vez mais difícil de justificar quando crescimento de curto prazo, velocidade de entrega e lock-in importam mais do que a manutenibilidade de longo prazo ou a experiência do usuário. Comentadores relacionam essa “enshittification” do software a incentivos desalinhados, concorrência fraca, métricas ruins para qualidade e práticas de gestão que recompensam lançar rápido em vez de construir sistemas duráveis e bem testados. Alguns argumentam que open source, concorrência mais forte ou culturas orientadas por missão podem conter essa tendência, mas observam que qualidade alta é cara, difícil de medir e muitas vezes só é valorizada quando sua ausência se torna catastrófica.
Natureza de “Qualidade” e Simplicidade
- Vários argumentam que código de qualidade tende a ser simples/descomplicado, mas observam que muitos domínios têm complexidade irredutível.
- Faz-se a distinção entre “complexo” (necessário) e “complicado” (gambiarra, camadas, soluções improvisadas).
- Alguns veem qualidade como modularidade, para que juniores consigam raciocinar sobre partes pequenas; outros dizem que “qualidade” é subjetiva e muito debatida (APIs, arquiteturas, linguagens, testes).
Incentivos, Competição e Enshittification
- Muitos relacionam a queda da qualidade a monopólios/travamento: uma vez que os usuários estão capturados, o ROI favorece crescimento, anúncios e “moats” em vez de refinamento.
- Outros enquadram isso como capitalismo geral/pensamento de curto prazo: maximizar receita no curto prazo vence a saúde do produto no longo prazo em quase todo setor.
- Contraponto: qualidade ruim também existia em sistemas não capitalistas; usuários toleram software barato “bom o bastante”.
- Alguns veem o open source como a resposta de longo prazo: tornar a infraestrutura uma commodity; o grande dinheiro está nos monopólios de efeito de rede.
Testes, QA e Prática de Engenharia
- Vários comentários lamentam a eliminação ou o enfraquecimento de QA; os devs “deveriam” testar, mas em geral não testam, e não são incentivados.
- Esforços de qualidade costumam vir de baixo para cima, de engenheiros que se importam; pressões de cima para baixo só funcionam quando a liderança as prioriza explicitamente e aceita o impacto no cronograma.
- Testabilidade e refatoração são vistas como caras no começo, mas mais baratas do que catástrofes de dívida técnica e reescritas.
Gestão, Produto e Dinâmicas Organizacionais
- Gerentes de produto são criticados por falta de profundidade técnica e por disfarçar decisões técnicas como requisitos.
- Rotação de recursos e “rebranding” para chamar atenção da imprensa são culpados por piorar produtos maduros.
- Sistemas de desempenho (ciclos curtos de revisão, stack ranking, obsessão por KPIs) recompensam recursos visíveis em vez de qualidade invisível ou trabalho de prevenção.
- Desenvolvimento orientado por currículo e permanências curtas desincentivam o cuidado de longo prazo.
Medir e Pagar por Qualidade
- Qualidade é difícil de vender porque é difícil de medir; os benefícios aparecem como custos futuros evitados e redução de churn.
- As pessoas invocam “dívida técnica” como uma metáfora comunicável; propõem uma “dívida de produto” semelhante.
- Alguns argumentam que “qualidade é cara”, outros que a falta de qualidade é mais cara ao longo do tempo; o ponto ótimo é “bom o bastante”, não perfeição.
Debate Sobre a Palavra “Enshittification”
- Um subthread debate o próprio termo: alguns o consideram vívido e preciso; outros o veem como cringe, pouco sério ou vulgar para uso mainstream/acadêmico.
- Alternativas propostas incluem “platform decay”, “management decay”, “rent seeking” e “platform arson”, com discordância sobre se capturam a intencionalidade e a força emocional.