todo dia era dia de indio — por que paramos de questionar processos que não fazem sentido
Na empresa onde eu trabalhava, tinha um relatório que gerávamos toda segunda-feira. Levava 47 minutos para rodar. Ninguém sabia exatamente por quê. O sistema legava planilhas, consultava tabelas repetidas, e finalizava com um exportação manual para Excel. Perguntei na primeira reunião de otimização se podia verificar o script. O cara que mantinha olhou pra mim como se eu tivesse falado algo ofensivo. Disse que "sempre foi assim". A expressão veio à minha cabeça naturalmente: todo dia era dia de indio. Ninguém questionava porque achavam que havia uma razão histórica importante, quando na verdade era só preguiça de reavaliar. Descobri em quinze minutos que a consulta principal buscava dados de uma tabela que já estava sendo agregada por outra. O join duplicava registros antes da agrupação. Removi a redundância e o relatório passou a rodar em onze minutos. Não foi um tweak milagroso. Foi só parar de tratar o existente como sagrado.
todo dia era dia de indio no dia a dia técnico
O problema não é só em relatórios. Atinge arquitetura, deploy, manutenção, revisão de código. Você vê gente manter um procedimento porque "é o que a documentação diz" ou "o responsável anterior pensou que era necessário". A maioria desses casos se resolve com uma pergunta simples: o que acontece se eu remover isso? Um exemplo concreto que vejo recorrentemente: pipelines de dados com transformações intermediárias que ninguém mais lê. O pipeline faz ETL, salva um DataFrame temporário em disco, e na etapa seguinte lê esse arquivo. O arquivo existe há três anos. Ninguém mais usa os dados que ele guarda. Remover essa etapa reduz o tempo de execução em cerca de trinta e dois por cento e elimina um ponto de falha que já causou dois incidents no último ano só por descompasso de esquema.
O que as pessoas esquecem é que todo sistema tem custo de manutenção proporcional ao seu tamanho. Cada peça adicional exige monitoramento, documentação, teste. Quando você adiciona complexidade sem necessidade, está criando dívida técnica silenciosa. E essa dívida não aparece no relatório de bugs. Ela aparece como lentidão, como retrabalho, como aquela chamada de emergência às quatro da manhã. Há uma armadilha comum aqui. Alguns times confundem estabilidade com imutabilidade. Achar que nunca se deve tocar em algo que funciona é confundir dois conceitos diferentes. Um sistema pode ser estável porque é bem projetado, não porque ninguém ousa mexer. A diferença importa. O primeiro permite evolução. O segundo entrincheira.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Minha abordagem prática é a seguinte. Antes de aceitar um processo como dado, peço para o responsável explicar cada etapa em voz alta. Se ele não consegue, ou se a explicação depende de "é assim mesmo", eu testo a remoção em ambiente controlado. Na maioria das vezes, nada quebra. Nas raras vezes que quebra, o problema era invisível e agora ficou visível. O que é, honestamente, um resultado positivo. Um caso específico que vale registrar: tínhamos um serviço de notificação que lia uma fila de eventos e enviava emails. Havia um workaround implementado para contornar um bug que já havia sido corrigido na base três versões antes. O workaround enviava duplicatas de um em cada cinquenta eventos. Removeu-se a correção antiga e o bug antigo não voltou porque o patch de base continuava válido. O resultado foi uma redução de carga no serviço de quarenta por cento e zero regressões. O risco de manter o workaround era maior do que o risco de removê-lo.
Outro ponto que poucos consideram: a pressão social para não questionar. Às vezes o processo não é ruim por si só. É ruim porque as pessoas se sentem ameaçadas se ele for desmontado. Se você é o guardião de um procedimento complexo, alguém que simplifica pode parecer uma ameaça à sua relevância. Isso não é lógico, mas é real. Eu já vi gente proteger código ruim não por convicção técnica, mas por insegurança profissional. Reconhecer isso ajuda a separar o argumento técnico do argumento pessoal. Se você está lidando com algo parecido, comece pelo menor item possível. Escolha uma etapa que pareça óbvia, mas que não tenha evidência clara de valor. Meça o estado atual. Remova. Meça de novo. Se não houver perda mensurável, documente a remoção e avance. Se houver perda, o registro te mostra exatamente onde estava o valor real. Em ambos os casos você sai ganhando informação.
Não existe solução perfeita. Às vezes o processo legado é realmente necessário por uma restrição externa que não está documentada. Pode ser compliance, pode ser integração com um sistema de terceiro, pode ser uma dependência real. A regra não é "remover tudo que parece desnecessário". A regra é "testar antes de assumir". A diferença é pequena, mas faz tudo. O que eu vejo na prática é que a maioria dos processos que sobrevivem por anos sem questionamento não têm razão de existir. Têm tradição. E tradição, em engenharia, é apenas preguiça bem disfarçada. Se você quer mudar isso, não precisa de uma reforma completa. Precisa de coragem para perguntar em voz alta o que todo mundo já desconfia em silêncio.
Isso não significa que deva ser feito de forma agressiva. Ninguém gosta de ser confrontado. A forma mais eficiente é apresentar dados, não opiniões. Mostre o before e o after. Deixe que os números façam o trabalho. Quando os números são claros, a resistência diminui rapidinho. No final, a expressão todo dia era dia de indio resume um comportamento que custa caro. Custa tempo, custa saúde mental da equipe, custa dinheiro de infraestrutura. E o mais irritante é que a correção quase sempre é simples. Só exige que alguém tome a iniciativa de olhar com frescor para algo que todo mundo já deu como resolvido.
