Quando vale a pena ir contra a corrente em desenvolvimento de software
Na maioria dos projetos, a resposta certa já existe. Tem artigo no Medium, tem vídeo no YouTube, tem documentação oficial. Eu vi gente passar três semanas implementando uma solução customizada porque achava que ia resolver um problema que já tinha sido resolvido na terceira versão do framework. Não vale. Mas existem cenários em que seguir o padrão te coloca em um beco sem saída. Aí sim, o caminho menos percorrido deixa de ser vaidade técnica e vira estratégia pura.
o caminho menos percorrido
A regra prática que eu uso é simples: quando a solução padrão exige mais de 60% do esforço total do projeto, ou quando ela cria uma dependência que trava seu roadmap por mais de seis meses, você para e avalia alternativas. É nesse cruzamento que as coisas interessam. Um exemplo concreto que tenho na cabeça envolve migração de banco de dados. Tinha um sistema legado rodando em PostgreSQL 9.4 com triggers personalizadas, stored procedures em PL/pgSQL, e um volume de dados de cerca de 2 terabytes. A solução padrão seria migração direta para PostgreSQL 15 usando pg_upgrade. Funciona na teoria. Na prática, pg_upgrade falha com triggers que usam variáveis declaradas de formas específicas que mudaram entre versões. Eu tentei. Dois dias de tentativa e erro, logs cheios de erro desconhecido, e no final o banco novo não subia.
A solução convencional pedia rebuild completo das triggers e testes extensivos de cada stored procedure. Isso daria aproximadamente seis semanas de trabalho. Em vez disso, usei uma abordagem paralela: mantive o PostgreSQL 9.4 rodando em produção, implementei um serviço de replicação bidirecional com pgpool-II pointando para uma instância nova com PostgreSQL 15, populei a nova instância via pg_dump incremental por janelas de manutenção de 15 minutos, e depois fiz cutover com failover planejado. O resultado foi uma migração em 10 dias com janela de downtime de 4 minutos. A solução óbvia nunca teria funcionado. A inviável funcionou. Isso é o cerne do conceito: o caminho menos percorrido não é sobre ser diferente por ser diferente. É sobre reconhecer quando o padrão se tornou um obstáculo e mapear um rota alternativa que contorna o ponto de falha.
👉 Clique no botão abaixo para saber mais sobre o assunto!
O problema é que a maioria dos engenheiros não sabe distinguir entre "o padrão não funciona aqui" e "eu não estou conseguindo fazer o padrão funcionar". A linha é tênue. Antes de abrir mão da abordagem convencional, eu sempre faço três verificações: primeiro, leio os issues abertos no repositório oficial do projeto para ver se alguém já encontrou exatamente o mesmo caso. Segundo, rodo o setup mais simples possível antes de escalar a complexidade. Terceiro, pergunto explicitamente em fóruns técnicos antes de gastar mais de dois dias em uma solução customizada. Uma coisa que pouca gente leva em conta é o custo oculto de manutenção. Uma solução não padronizada que economiza duas semanas de desenvolvimento pode custar dois meses de manutenção futura se ninguém mais no time entende como funciona. Eu já herdei código onde o desenvolvedor anterior decidiu que a melhor abordagem era evitar completamente um ORM e escrever queries brutas em SQL com orquestração manual de conexões. O código era rápido. Era também incompreensível para qualquer pessoa que não tivesse estado presente durante a implementação. Quando essa pessoa saiu da empresa, o sistema ficou parado por três semanas até que alguém conseguisse fazer uma mudança simples.
O equilíbrio existe. A minha diretriz é: se a solução alternativa usa apenas tecnologias e padrões já conhecidos pela equipe, o risco de manutenção é baixo. Se ela introduz novas tecnologias, novas arquiteturas ou novas abstrações, o custo futuro sobe exponencialmente. Um script Python para automação interna que usa apenas bibliotecas padrão? Vai bem. Uma reescrita completa em Elixir porque "o padrão em Python é lento"? Ai que está o problema. Também há situações onde o caminho menos percorrido simplesmente não existe. Alguns problemas são bem resolvidos por soluções bem conhecidas porque essas soluções foram testadas em escala industrial. Microserviços para um sistema com menos de mil usuários ativos, containerização para uma aplicação monolítica simples que roda em um único servidor — nesses casos, a complexidade extra da solução avançada não traz benefício proporcional. O overhead administrativo e operacional consome mais tempo do que qualquer economia que você obtenha.
Para quem quer aplicar esse tipo de raciocínio no dia a dia, comece com problemas pequenos. Escolha um desafio técnico dentro do seu projeto atual e liste as três soluções mais óbvias. Para cada uma, estime o tempo de implementação, o tempo de manutenção projetado e o risco de quebrar algo em produção. A solução que parecer mais atraente no papel muitas vezes esconde custos que só aparecem após a implantação. A que parece mais chata ou complicada pode ser a que entrega valor real com menor atrito. O caminho menos percorrido é útil quando o caminho usual leva a um parede. Não é uma filosofia de vida técnica. É uma ferramenta de diagnóstico que funciona melhor quando usada com parcimônia e rigor. Se você aplicar para tudo, vira apenas mais um padrão. E aí voltou ao começo.
