O Ciclo Vicioso Que Devora Software Houses Por Dentro
Na minha experiência com mais de 300 software houses, existe um padrão que se repete com precisão cirúrgica: programador novo entra, olha o código existente, torce o nariz e declara que “precisa reescrever tudo”. A empresa, acreditando que está investindo em qualidade, aprova. O resultado? Depois de 20 anos, o sistema virou um Frankenstein de linguagens, frameworks e padrões que ninguém consegue manter.
Esse fenômeno não é exclusivo de empresas pequenas, mas é nelas que o estrago é mais devastador. Enquanto grandes corporações têm processos de governança e arquitetos dedicados, a software house de 5 a 20 desenvolvedores opera na base do “cada um faz do seu jeito”. E isso tem um custo que poucos calculam.
Segundo dados recentes, 93% das equipes de desenvolvimento reportam conviver com dívida técnica significativa, e organizações que ignoram essa dívida gastam até 40% a mais em manutenção do que aquelas que a tratam de forma estratégica.
A Anatomia do Código Frankenstein
O padrão é sempre o mesmo. O fundador contrata o primeiro desenvolvedor, geralmente alguém que manja de Delphi ou PHP, e o MVP nasce. Funciona, vende, os clientes chegam. Dois anos depois, esse dev sai e entra outro que programa em Java. Ele olha o código PHP e diz: “Isso aqui é lixo, preciso reescrever em Java”. A empresa aceita.
Cinco anos depois, o dev Java sai. Entra alguém de Node.js. O ciclo se repete. Mais cinco anos, entra alguém de Python. Mais uma reescrita. O resultado em 20 anos é um sistema com pedaços em quatro linguagens diferentes, cada camada seguindo um padrão arquitetural distinto, e documentação que existe apenas na cabeça de pessoas que já saíram da empresa faz tempo.
Na prática, o que acontece é:
- Camada 1 (2006): Backend em Delphi com regras de negócio no banco de dados
- Camada 2 (2010): Módulo novo em Java, integrado via web services SOAP com a camada Delphi
- Camada 3 (2015): API REST em Node.js que conversa com o Java e ignora o Delphi
- Camada 4 (2020): Microsserviços em Python que só funcionam se todas as outras camadas estiverem de pé
Cada camada foi escrita por alguém que considerava a anterior “legado inaceitável”. A ironia é que cada uma dessas camadas virou, ela mesma, o legado do próximo.
Por Que Reescrever Quase Nunca é a Resposta
Joel Spolsky, cofundador do Stack Overflow, chamou a reescrita total de código de “a pior decisão estratégica que uma empresa de software pode tomar”. E os dados confirmam: a maioria das reescritas greenfield nunca chega a ser lançada. A empresa gasta meses (às vezes anos) desenvolvendo a nova versão enquanto ainda precisa manter a antiga funcionando. O time se divide, os bugs se multiplicam e o custo explode.
O problema fundamental é que código antigo carrega conhecimento implícito. Aquela condição estranha no if que ninguém entende? Provavelmente resolve um bug que apareceu em produção em 2014 e que ninguém documentou. Quando você reescreve, perde esse conhecimento. E aí o bug reaparece, só que agora ninguém sabe que ele já existiu.
De acordo com pesquisa da Qt Group, CIOs estimam que entre 10% e 20% do orçamento técnico destinado a novos produtos acaba sendo desviado para resolver problemas de dívida técnica. Esse número sobe dramaticamente em empresas que optaram por reescritas mal planejadas.
O Ego do Programador e o Custo Para o Negócio
Vou ser direto: boa parte das reescritas não acontece por necessidade técnica real. Acontece por ego. O programador novo quer deixar sua marca. Quer usar a tecnologia que ele domina, não a que a empresa já usa. E muitas vezes o gestor, que não é técnico, não tem como questionar.
Na minha visão, isso é uma falha de gestão, não de tecnologia. Se cada novo membro do time tem autonomia para propor uma reescrita completa, e se a empresa não tem critérios objetivos para avaliar quando isso faz sentido, o Frankenstein é inevitável.
O custo real vai muito além do salário do programador:
- Perda de velocidade comercial: enquanto reescreve, a empresa não entrega features novas para clientes
- Risco de regressão: funcionalidades que funcionavam param de funcionar na versão nova
- Dependência de indivíduo: só quem reescreveu entende a nova versão, criando um novo ponto único de falha
- Custo de oportunidade: o tempo gasto reescrevendo poderia estar gerando receita com novas features
A Alternativa: Refatoração Estratégica e a Regra do Escoteiro
A abordagem que realmente funciona não é glamorosa e não vai virar post no LinkedIn, mas salva empresas: refatoração contínua e incremental. Michael Feathers, autor de “Trabalho Eficaz com Código Legado”, defende que você não precisa reescrever para melhorar. Precisa criar testes, isolar dependências e melhorar aos poucos.
A Regra do Escoteiro aplicada ao código diz: “Deixe o código um pouco melhor do que você encontrou”. Não precisa reescrever o módulo inteiro. Corrigiu um bug? Melhore a legibilidade daquela função. Adicionou uma feature? Escreva testes para a área que você tocou. Com o tempo, o código melhora organicamente sem o risco catastrófico de uma reescrita.
Para software houses que já estão nessa situação de Frankenstein, eu recomendo uma abordagem em três frentes:
- Congele a expansão: Proíba novas linguagens e frameworks até que haja um plano arquitetural documentado e aprovado
- Crie uma camada de abstração: Use APIs internas para isolar as diferentes linguagens, permitindo que cada módulo evolua independentemente
- Defina um padrão: Toda nova feature segue o mesmo padrão, na mesma linguagem, com os mesmos critérios de qualidade
O Papel da IA na Gestão de Código Legado
Uma coisa que mudou drasticamente nos últimos meses é que ferramentas como o Claude Code e o GitHub Copilot tornaram a manutenção de código legado muito menos dolorosa. Na minha experiência, um desenvolvedor usando IA consegue entender e navegar código legado em uma fração do tempo que levaria manualmente.
Isso muda completamente a equação “reescrever vs. refatorar”. Se antes o argumento era “ninguém entende esse código Delphi de 2008”, agora a IA entende. Ela lê, explica, sugere melhorias e até gera testes para código que nunca teve cobertura. O custo de manter código legado caiu dramaticamente, o que torna a reescrita total ainda menos justificável.
Segundo a Growth Acceleration Partners, 60% das organizações reportam que sua dívida técnica aumentou materialmente nos últimos três anos, especialmente à medida que correm para modernizar sistemas para demandas de IA e automação. A boa notícia é que a própria IA se tornou a ferramenta mais eficaz para lidar com esse problema.
Conclusão: Pare de Criar Monstros
O Código Frankenstein não é um problema técnico. É um problema de gestão. Cada vez que sua software house permite que um programador novo reescreva tudo do zero, está adicionando uma nova camada ao monstro. A confusão de 20 anos não acontece de uma vez; ela se acumula decisão por decisão.
A solução não é proibir mudanças. É criar processos que garantam continuidade: padrões arquiteturais documentados, code reviews rigorosos, refatoração contínua e um critério claro e objetivo para quando (e se) uma reescrita se justifica. Na era da IA, manter e evoluir código legado ficou mais fácil do que nunca. O argumento de “ninguém entende isso” simplesmente não cola mais.
Quer ver como isso funciona na prática? Assista ao vídeo completo onde explico esse padrão em detalhes: Código Frankenstein: A Saga das Empresas Pequenas.
