Quem nunca se empolgou com uma nova tecnologia, um padrão arquitetural interessante ou um case de sucesso de uma big tech e pensou: “por que não aplicar isso aqui também?” A verdade é que esse impulso, embora nasça de uma boa intenção, pode nos levar direto para a armadilha do over engineering, um problema mais comum do que parece.

Neste artigo, quero compartilhar reflexões sobre o que é over engineering, como identificá-lo, por que caímos nessa armadilha e, principalmente, como evitamos esse excesso aqui no Asaas, sem abrir mão da qualidade do que construímos.

O que é over engineering?

Over engineering é quando criamos uma solução mais complexa do que o necessário para resolver o problema que temos no momento.

É como instalar um sistema automatizado de irrigação com sensores, temporizadores e integração com a previsão do tempo só para cuidar de um vasinho de planta que poderia ser regado com um copo d’água.

A metáfora pode parecer exagerada, mas traduz bem a essência do problema: estamos colocando energia e recursos demais para resolver algo que, na prática, poderia ser simples.

O grande perigo está no impacto desse excesso: atrasos em entregas, aumento da complexidade do código, dificuldade de manutenção, curva de aprendizado maior e, muitas vezes, pouco ou nenhum valor adicional para o cliente final. E o pior: tudo isso parte, na maioria das vezes, de boas intenções.

Como identificar que estamos caindo nessa armadilha?

Existem alguns sinais que nos ajudam a perceber quando estamos indo além do necessário:

• Excesso de abstração para pouca funcionalidade: Quando criamos interfaces, serviços e camadas demais para algo que, no fundo, faz pouca coisa.
• Código difícil de entender e explicar: Se você precisa de dez minutos para explicar uma função, talvez ela esteja mais complexa do que deveria.
• Uso de padrões e ferramentas “por padrão”, sem uma razão real: Muitas vezes, adotamos estruturas porque estão na moda ou porque lemos sobre elas em artigos técnicos, mas esquecemos de nos perguntar se realmente precisamos daquilo.
• Pouco valor entregue depois de muito esforço: O retrato clássico de um time que trabalhou muito, mas entregou pouco.
• Quando você precisa abrir mais de 5 diagramas para explicar sua estrutura.
• Decisões baseadas em achismos, e não em dados ou necessidades reais.

Já presenciei situações em que uma simples integração com outro sistema foi pensada como uma arquitetura robusta de orquestração de eventos, com filas, retries e fallback, tudo isso antes mesmo de sabermos se o sistema parceiro era estável ou se o volume de uso justificava tanta preparação. Quando isso acontece, o risco de criarmos algo desnecessariamente complicado é enorme.

Por que isso acontece?

Over engineering geralmente nasce de uma combinação de fatores. Alguns deles:

• Insegurança técnica: O medo de errar faz com que a gente tente se proteger com soluções “à prova de tudo”.
• Desejo de mostrar domínio técnico: Às vezes, queremos mostrar que sabemos muito e, sem perceber, deixamos de lado a simplicidade.
• Influência de grandes empresas: Consumimos muitos conteúdos de empresas como Google, Amazon, Netflix, que lidam com desafios de escala imensos. Aplicar as mesmas soluções fora desse contexto pode ser um erro.
• Liberdade excessiva: A ausência de padrões ou direcionamento pode fazer com que cada desenvolvedor tome decisões por conta própria, levando a soluções inconsistentes e, muitas vezes, superdimensionadas.
• FOMO (Fear of Missing Out): A ansiedade de estar por dentro de tudo o que é novo pode nos levar a adotar tecnologias ou práticas antes mesmo de saber se são úteis para o nosso caso.

Como equilibrar robustez e simplicidade?

Aqui no Asaas, temos um esforço constante para buscar esse equilíbrio. Como liderança técnica, procuramos estimular o time com perguntas provocativas, como:

“Isso resolve o problema de hoje ou o que talvez surja mês que vem?”

“Qual volume (requests, dados, usuários) atual?”

“Testamos uma versão mais simples antes de chegar nessa proposta?”

Valorizamos soluções simples e bem feitas tanto quanto aquelas mais elegantes e complexas. Buscamos criar um ambiente em que o “simples que funciona“ tem espaço, é reconhecido e celebrado. Isso ajuda a frear o impulso de complicar sem necessidade.

O que fazemos para evitar o over engineering

No dia a dia, algumas práticas têm nos ajudado bastante:

• Revisões de PR com foco em clareza e propósito: Mais do que encontrar bugs, usamos os PRs para avaliar se a solução faz sentido, segue nossos padrões, é fácil de manter e resolve o problema real.
• Propostas técnicas antes do desenvolvimento: Isso nos permite alinhar expectativas e evitar surpresas no meio do caminho.
• Construção de MVPs reais, ou seja, não só no produto, mas também na arquitetura: Entregar uma primeira versão enxuta da arquitetura permite validar hipóteses com menor custo. Isso sem deixar de lado a qualidade da entrega.
• Documentação técnica com princípios e padrões claros (aqui no Asaas conhecido como o “Livro de Elite”).
  

Quando a complexidade é necessária e como reconhecê-la

Nem toda complexidade é ruim. Às vezes, ela é necessária, e fugir dela seria até irresponsável. Mas há uma diferença importante entre complexidade necessária e over engineering.

A complexidade necessária vem depois da evidência. Ela aparece quando testamos uma abordagem simples e ela não foi suficiente. Quando sabemos, com dados, que falhas terão impacto alto demais. Quando o sistema exige algo mais robusto.

Já o over engineering é o oposto. A complexidade aparece antes da evidência, baseada em suposições, medos ou vaidade técnica.

Conselhos para devs que querem fugir dessa cilada

Se você está começando na área, alguns conselhos podem ajudar:

• Antes de sair codando, pergunte: “qual a forma mais simples de resolver isso?
• Valide sua ideia com alguém mais experiente ou pergunte-se: “estou resolvendo um problema real ou um cenário hipotético?”
• Pratique o YAGNI (You Aren’t Gonna Need It): não implemente algo que talvez só vá precisar no futuro.
• E lembre-se: soluções simples bem executadas são quase sempre melhores do que ideias geniais mal encaixadas.
  

Como se manter no foco

Costumo repetir algumas frases para ajudar a manter os pés no chão:

“Isso aqui resolve o problema ou apenas massageia meu ego?”

“Código que ninguém entende é bug esperando acontecer.”

“A solução certa no momento errado é, de certa forma, a solução errada.”

Vivemos cercados por conteúdos de alto nível técnico, muitos deles escritos por profissionais que enfrentam desafios diferentes dos nossos. Sem contexto, aplicar essas soluções pode ser mais um problema do que uma vantagem.

Até mesmo ferramentas de IA podem sugerir arquiteturas excessivamente complexas, porque são alimentadas pelos mesmos conteúdos. Por isso, mais do que saber muito, é preciso saber quando aplicar o que se sabe.

No fim, o desafio não é só construir soluções sofisticadas, mas sim entregar valor com leveza, clareza e foco no que realmente importa. E isso, na Engenharia do Asaas, é um princípio que nos guia todos os dias.