É a fantasia mais sedutora da engenharia de software: apagar tudo e começar do zero, "agora do jeito certo". Todo CTO já a teve; os melhores aprenderam a desconfiar dela.

Joel Spolsky escreveu o texto definitivo sobre o assunto ao analisar o caso Netscape, que reescreveu o navegador do zero e entregou o mercado ao concorrente (Things You Should Never Do). O argumento central envelheceu bem: código antigo e feio funciona, e cada trecho estranho é uma correção de bug que alguém pagou para aprender. Jogar o código fora é jogar fora anos de conhecimento que não está documentado em lugar nenhum.

Por que reescritas quebram a cara (com tanta frequência)

• O alvo se move: enquanto o time reescreve, o produto velho precisa continuar evoluindo. A reescrita persegue um alvo que anda, e chega atrasada ao lugar onde ele estava.
• A paridade é um iceberg: "fazer o que o sistema atual faz" parece um requisito; são milhares, e a maioria invisível: o desconto especial de um cliente, o ajuste de fuso, o caso raro que só acontece em fevereiro.
• O efeito segundo sistema: descrito por Fred Brooks no clássico The Mythical Man-Month: a segunda versão é a mais perigosa, porque o time desconta nela todas as ambições reprimidas. Nasce superdimensionada.
• Dois sistemas, um time: durante a transição, mantém-se o velho e constrói-se o novo. O custo real é quase sempre o dobro do estimado, com congelamento de roadmap no meio.

Quando a reescrita se justifica de verdade

Existem casos legítimos, e eles são específicos:

1. A plataforma morreu: linguagem/framework sem suporte, sem talento no mercado, sem patch de segurança. Não é preferência; é fim de linha.
2. O custo de mudança superou o de reconstrução, comprovadamente: com as métricas de dívida mostrando lead time e retrabalho insustentáveis depois de tentativas honestas de refatoração.
3. O modelo de negócio mudou de espécie: o sistema foi desenhado para um problema que não é mais o problema (de licença local para SaaS multi-tenant, por exemplo).
4. Escala estruturalmente impossível: limites de arquitetura que nenhuma otimização incremental alcança, com evidência, não com opinião.

Se o argumento é "o código está feio" ou "ninguém entende ele", a resposta não é reescrever: é a rede de testes e a refatoração que devolvem o entendimento.

A terceira via (que vence quase sempre): evoluir por substituição

Entre "reformar tijolo a tijolo" e "dinamitar o prédio", existe a via que combina os dois: substituição incremental via strangler fig. O sistema novo nasce por fatias, cada fatia assume tráfego real, o velho encolhe até desaparecer. Sem big bang, sem paridade-iceberg (cada fatia define seu escopo), sem congelar a roadmap, com rollback a cada etapa.

O detalhe que faz funcionar: começar pela fatia que dá retorno, não pela mais fácil. Se o módulo de checkout é o gargalo do negócio, ele é a primeira figueira, e paga a transição inteira.

O checklist da decisão honesta

Antes de assinar qualquer reescrita, exija respostas por escrito:

• O que exatamente o sistema atual nos impede de fazer, em números?
• Já tentamos refatoração dirigida nos hotspots? O que aconteceu?
• Qual é o plano para o produto durante a transição: congela ou anda?
• Qual é o critério de paridade: tudo, ou o essencial redefinido?
• Se a reescrita atrasar 2x (a média do mercado), a conta ainda fecha?

Reescrita que sobrevive a essas cinco perguntas merece acontecer. A maioria não sobrevive à primeira.

Uma decisão cara demais para o achismo

Esse diagnóstico (métricas do sistema atual, análise de alternativas e o desenho da transição, seja qual for o caminho) é exatamente o tipo de trabalho do nosso serviço de Manutenção e Evolução. Entregamos o estudo com números; a decisão fica fácil quando ela para de ser opinião.

Está com essa decisão na mesa agora? Descreva o sistema e a dor para a IA da Rabelo Digital, aqui no canto da tela, e ela percorre o checklist com você. Sem formulário, sem espera.

---

Leia também

• Débito técnico: como medir e quando pagar
• Refatoração sem medo