A Maturidade Final Entre Reescrever e Resignação Introdução: O Dilema Real Todo senior em tecnologia chega a um ponto na carreira em que enfrenta um sistema legado que funciona, mas incomoda. É o sistema que paga as contas, que processa transações críticas, que segura clientes importantes—e que, simultaneamente, paralisa a velocidade de inovação. Ele não está quebrado. Exatamente aí mora o problema: não está quebrado o suficiente para justificar um rewrite de 2-3 anos, mas está estável o suficiente para que a organização continue negligenciando-o. A decisão que enfrenta não é técnica, é estratégica. E ela define a maturidade final de um CTO, arquiteto ou engenheiro sênior: saber quando reescrever é erro catastrófico, e como evoluir sem parar o negócio. Este artigo coloca duas mentiras lado a lado e as queima. A primeira: “Devemos reescrever tudo do zero.” A segunda: “Devemos apenas refatorar incrementalmente para sempre.” A realidade que separa amadores de especialistas está nos degraus entre essas extremidades. Parte 1: Quando Reescrever é um Erro Catastrófico O Fantasma da Taxa de Falha Não existe consenso acadêmico sobre qual é exatamente a taxa de fracasso de rewrites completos. Mas existem evidências suficientes. McKinsey relata que 70% dos programas de transformação em larga escala não alcançam seus objetivos. A Thoughtworks e a comunidade de engenheiros documentam um padrão recorrente: rewrites sobreestimam o que conseguem fazer e subestimam o que perdem. Por que isso acontece? Porque um rewrite completo confunde “começar do zero” com “resolver o problema”. Na verdade, o que está acontecendo é muito mais sinistro: Você não está reconstruindo o sistema. Você está reconstruindo o conhecimento. Um sistema legado de 10-20 anos não é apenas código. É um repositório de decisões de negócio: casos extremos tratados em patches, integrações quirky que ninguém lembra por quê, dados limpos lentamente em triggers noturnos. Tudo isso é conhecimento tácito. Quando você reescreve, você tira esse conhecimento da base de código e o coloca na cabeça de engenheiros novos—ou, piores, em whiteboards onde ele é esquecido. Um engenheiro experiente que trabalhou em sistemas legados grandes conhece a história verdadeira. O rewrite não falha porque os engenheiros são incompetentes. Falha porque: O resultado é previsível: dois em cada três projetos assim não terminam, ou terminam com tempo e orçamento 2-3x maiores que planejado, com sêniors cassados, e equipes queimadas. O Caso Que Ninguém Quer Contar Há uma razão pela qual você vê mais artigos sobre “como fazer um rewrite direito” do que “aqui está a mensagem de erro que você vê quando um rewrite inteiro falha e precisa ser cancelado.” Os que falham não escrevem cases—eles silenciosamente desaparecem, e os líderes nunca falam sobre eles em conferências. Mas há sinais. Reddit tem threads de engenheiros experientes dizendo coisas como: “Big Bang rewrites têm uma taxa de fracasso tão alta que é provável você ver a equipe antiga ser demitida depois de 2-3 anos de não-entrega que a equipe nova conseguir sucesso.” Isso é raiva documentada, não especulação. Parte 2: O Custo Real de Não Fazer Nada Agora, antes que você conclua “então simplesmente deixamos o sistema legado em paz,” entenda o outro lado do dilema. Um sistema legado que apenas mantém o status quo é um dreno financeiro. Os custos são menos óbvios que um rewrite falhando, mas são muito mais devastadores ao longo do tempo. Dinheiro Que Você Não Vê Deixando Uma manufatura típica, por exemplo, paga até $260.000 por hora em custos de downtime não planejado. Se o seu sistema legado falha uma vez a cada trimestre por 2 horas (porque ninguém quer mexer nele, então acumula dívida técnica), você está perdendo $1 milhão por ano apenas em downtime—sem contar recuperação, perda de produtividade, ou reputação. Serviços financeiros? Até $9.000 por minuto. Se você tem um sistema crítico de processamento de reclamações que falha sem aviso porque ninguém teve coragem de refatorar aquela seção acoplada do código, uma falha de 1 hora custa $540.000. Várias dessas ao ano, e você está falando de múltiplos milhões. Mas os custos mais insidiosos são invisíveis: Um estudo da Flexera mostra que custos de manutenção para sistemas legados crescem ano a ano, enquanto capacidade produtiva cai. Isso é uma curva de morte. Em algum momento, custa mais manter a coisa do que reconstruir. A Bomba de Conhecimento O sistema legado também tem outro inimigo invisível: pessoas. O engenheiro que escreveu 60% da lógica aposentou. O outro está aceitando uma oferta melhor e sai. Você fica com um sistema que ninguém entende completamente, que ninguém quer mexer, e uma mudança simples vira arqueologia. Quando o conhecimento tácito sai, o risco explode. Mudanças pequenas introduzem bugs inesperados. Ninguém tem confiança para refatorar. Você entra em espiral KTLO (Keep The Lights On): apenas manutenção reativa, nunca estratégica. Parte 3: Quando Reescrever Faz Sentido (Muito Raramente) Agora, a honestidade: há casos em que um rewrite é a decisão certa. Apenas muito mais raros que as pessoas pensam. Um rewrite completo faz sentido quando: Fora desses cenários específicos—que afetam talvez 10-15% dos sistemas legados em produção—um rewrite é uma aposta, não uma estratégia. Mesmo nesses casos, ainda há alternativas. Mas essa é a transição para a parte que importa: como você realmente moderniza sem o risco catastrófico do rewrite, e sem a resignação confortável de nunca mudar. Parte 4: O Padrão Strangler Fig—A Maturidade Final Existe um padrão que chegou perto de resolver esse dilema. Não é perfeito. Mas é tão mais próximo de realista que torna outras abordagens parecerem práticas de cargo culto. Chama-se Strangler Fig Pattern. O nome vem da biologia: uma figueira estranguladora cresce lentamente ao redor de uma árvore hospedeira. Ela não mata a árvore de uma vez. Envolve-a gradualmente, intercepta a luz e a água, até que eventualmente a árvore hospedeira morre de inanição—mas a figueira nunca precisa de um “big bang” para vencer. A transição é invisível. Em sistemas de software, o padrão funciona assim: O Conceito Básico Ao fim de 3-5 anos, o “novo sistema” é na verdade um bando de microsserviços lean que substituíram gradualmente cada função do monolith..
