Perfeição não é over-engineering: o vilão é o requisito mal definido

Perfeição não é o problema - requisitos mal definidos são

A indústria de software criou uma falsa equivalência entre buscar a solução perfeita e over-engineering. Frases como "não queremos fazer perfeito" se tornaram comuns, como se perfeição fosse um palavrão. Mas over-engineering não é "cuidar demais" nem "fazer bom demais" - é resolver o problema errado, geralmente com boas intenções e uma pilha crescente de complexidade incidental.

A solução perfeita existe (com uma condição)

Quando os requisitos são claros o suficiente - cada restrição na mesa - algo interessante acontece: resta apenas uma solução possível. E essa solução é, ironicamente, a perfeita. Ela é perfeita porque é a única que se encaixa. Escolher entre serverless e um servidor tradicional, entre Python e outra linguagem, entre Django e Flask - tudo depende das restrições. Restrições diferentes levam a respostas diferentes no mesmo espaço de problema. A solução perfeita para um caso pode ser errada para outro.

Sistemas são produtos

A causa raiz do over-engineering é quase sempre requisitos - e no sentido de produto, não apenas técnico. Bibliotecas, APIs e ferramentas internas não são "puramente técnicas". Elas têm usuários com necessidades reais. Talvez o que o usuário precisa seja um pacote, não uma chamada HTTP. A forma da solução só fica óbvia quando você trata o sistema como produto e define os requisitos com honestidade.

Como identificar over-engineering na prática

O sinal mais claro: quando você pergunta "por que as coisas são construídas assim?" e as respostas não se sustentam. Exemplo clássico: um time de três pessoas mantendo cinco microsserviços que compartilham dados entre si. O que era uma foreign key com integridade garantida pelo banco vira um ID solto em um campo. Um serviço deleta um registro e o outro só descobre depois, da pior forma. O ganho? Deploys independentes - mas esse problema sequer existia para três pessoas em um único domínio. O resultado: inconsistência distribuída, overhead operacional e um sistema que resolve vários problemas parcialmente, nenhum completamente, enquanto introduz problemas que não existiriam de outra forma.

O diagnóstico é simples, o trabalho não

Over-engineering é uma falha de levantamento de requisitos. É a consequência de coletar os requisitos errados e depois engenhariar diligentemente contra eles. A perfeição nunca foi a inimiga. Requisitos ambíguos são. Acerte-os, coloque cada restrição na mesa, e a solução perfeita deixa de ser fantasia - vira a única coisa que resta de pé.