For our Brazilian community, here’s a Portuguese version of the original post written by Robby Russell.
Existe um padrão que vemos se repetir o tempo todo.
Ouvimos isso em conversas com equipes de engenharia. Aparece em entrevistas de podcast com gente que já viu várias versões do “vamos reescrever tudo”. Surge nas conversas de corredor em conferências. E isso também aparece quando engenheiros experientes começam discretamente a procurar outro trabalho e têm dificuldade de explicar claramente o que deu errado.
“Uma hora a gente reescreve isso.”
Empresas diferentes. Stacks diferentes. A mesma dinâmica.
Quando as equipes chegam até nós, normalmente já estão num ponto de virada. Estão discutindo se deveriam reescrever um software do qual dependem totalmente, mesmo que ele ainda toque o negócio todos os dias. O sistema pode ter sido construído em Rails, Ember ou qualquer outra coisa. Ele reflete anos de trade-offs reais, pressão de clientes e decisões tomadas para manter o produto de pé. Algumas dessas decisões ainda fazem sentido. Outras nem tanto. O fato é que o software funciona... mas a relação da equipe com ele foi se desgastando com o tempo.
No momento em que alguém menciona reescrever o sistema, mesmo que de passagem, o ritmo do time começa a cair mesmo antes de qualquer coisa realmente quebrar.
Como a conversa sobre reescrever o sistema acaba desacelerando o time
A maioria dos times nunca chega a decidir, de verdade, reescrever o software. Sem anúncio. Sem orçamento. Sem cronograma. Nem uma decisão explícita.
Em vez disso, a ideia fica pairando.
Ela aparece como brincadeira. Uma piadinha no Slack. Um comentário numa reunião. “Sinceramente, a gente devia reescrever isso algum dia.” Ninguém discorda. Mas também ninguém se compromete. A reescrita vira uma possibilidade compartilhada — não um plano.
Para quem está na liderança, isso é fácil de não notar: oficialmente, nada mudou. Mas, psicologicamente, tudo mudou.
Quando algo passa a ser tratado como provisório, as pessoas param de assumir responsabilidade de verdade por aquilo. Não é por apatia — é por autopreservação. Quando o time começa a achar que o sistema é temporário, eles naturalmente investem menos tempo nele. Param de corrigir pequenas coisas. Param de aprofundar o entendimento do código. Param de melhorar aspectos do sistema que não têm retorno imediato.
Eles continuam tocando o sistema, mas meio que em modo de espera.
Refactors vão sendo adiados. Testes parecem menos urgentes. A documentação vai ficando para trás. Correções mais profundas só acontecem quando não tem mais como evitar. Os engenheiros também param de fazer melhorias quando deixam de acreditar que melhorias são realmente esperadas ou valorizadas.
De fora, isso pode parecer falta de motivação ou resistência a mudanças. Por dentro, parece mais um desligamento profissional. Deploys começam a parecer mais arriscados. Code reviews ficam mais conservadores. A noção de ownership começa a se perder. O time não está travado pelo código em si… está travado pela incerteza sobre se o trabalho que fazem hoje ainda vai importar amanhã.
Levantar a ideia de um rewrite é saudável. Deixar isso no limbo não é.
Vale deixar claro: é saudável que times, de tempos em tempos, se perguntem se um rewrite faz sentido. Fugir dessa pergunta não é cuidar bem do sistema. Sistemas envelhecem. O contexto muda. E às vezes recomeçar do zero realmente é a decisão certa.
O problema não é colocar rewrite em pauta. O problema é ficar falando de rewrite toda hora — e nunca concluir a discussão.
O que vemos na prática é que ao discutirem a possibilidade de um rewrite, acabam chegando à uma conclusão comum: continuar como está é a opção menos arriscada e mais pragmática. E então... nada acontece. Nada é documentado. A decisão não é compartilhada. Nenhum caminho alternativo é definido.
Assim, a conclusão evapora — mesmo que o resultado permaneça. É assim que a ideia de fazer um rewrite continua voltando.
Um ano depois, alguém novo entra no time e solta um comentário qualquer: “E se reescrevermos tudo do zero...”. E se ninguém responde de forma clara, o ciclo recomeça. O time volta a pensar no sistema como algo provisório, mesmo que a decisão já tenha sido tomada antes.
Quando um time decide não fazer um rewrite, essa decisão precisa ser firme e bem definida. Ela deve ser registrada, compartilhada e reforçada. Deve explicitar os riscos avaliados, explicar por que a substituição não era o melhor caminho e deixar claro com o que o time está se comprometendo em vez disso.
Isso não impede a discussão, mas impede que a conversa fique à deriva.
Por que esse padrão aparece com tanta frequência
Já escrevi sobre isso de forma mais direta em um texto que descreve os sete estágios de adoção de uma stack. A ideia não era definir um ciclo exato, mas dar nome a um arco comum que aparece quando um software sobrevive tempo suficiente para realmente importar.
No início, as equipes estão cheias de energia e otimismo. O sistema é pequeno, compreensível e fácil de mudar. À medida que o produto cresce, a pressão aumenta. Surgem guardrails. Processos crescem. Trade-offs se acumulam. Com o tempo, o software se torna mais completo... e mais pesado.
Eventualmente, muitos times chegam a um estágio em que o sistema ainda funciona, mas mudá-lo parece lento, arriscado ou emocionalmente exaustivo. É geralmente nesse momento que começa a surgir a conversa sobre reescrever tudo.
Não porque o software está falhando. Mas porque o time está cansado?
Para quem lidera produto ou engenharia, essa forma de pensar pode ser útil. Em vez de ficar discutindo se a tecnologia está “velha demais”, talvez a pergunta certa seja: em que ponto dessa arco o seu time está? Eles ainda estão animados e otimistas? Cautelosos, mas confiantes? Ou já meio resignados e desanimados?
A conversa sobre reescrever tudo normalmente aparece como um sintoma desse último estágio.
Por que a IA está trazendo essa pergunta à tona
Existe um acelerador nessa conversa hoje: a IA.
Muitos líderes estão, com razão, olhando para as novas ferramentas e pensando: “Agora dá pra ir mais rápido. Talvez seja a hora de reconstruir tudo.” Não é irracional fazer essa pergunta. Não é uma pergunta absurda. Se a IA realmente reduz atrito e acelera a entrega, então faz sentido aproveitar esse momento para repensar grandes apostas.
Mas é aqui que muitos times tropeçam.
A IA facilita começar coisas. Ela não remove as partes mais difíceis de uma reescrita. Ela não resolve a complexidade do domínio. Não migra dados com segurança. Não recria anos de edge cases. Não elimina o custo de rodar dois sistemas em paralelo durante a transição.
Se um time já carrega aquele clima de “um dia a gente reescreve isso”, a IA joga ainda mais lenha nessa fogueira. Não porque muda os fundamentos, mas porque cria uma narrativa conveniente — um jeito de evitar a responsabilidade de cuidar do sistema atual enquanto ao mesmo tempo parece algo ambicioso. E se o time não responder essa pergunta por conta própria, alguém vai responder. Em algum momento, um líder de produto, executivo ou alguém do board vai perguntar:
“Se a IA está deixando a gente mais rápido, por que não reescrever tudo? Seu time sequer parece motivado para manter o que já existe.”
Essa pergunta vai chegar. O melhor movimento é se antecipar a ela.
Como líderes podem redefinir a dinâmica
Em vez de correr para justificar uma reescrita, a abordagem mais eficaz é mudar as perguntas. Perguntas como:
- Estamos tratando esse software com a devida atenção?
- Que fricções do dia a dia o time já passou a aceitar como normais?
- Quais melhorias seguem sendo adiadas por não serem consideradas “estratégicas”?
- Se nada mudasse durante um ano, o que esgotaria a equipe primeiro?
Essas perguntas revelam comportamento e experiência, não arquitetura.
Um exercício que já vimos funcionar bem é pedir para o time imaginar que esse é o último código de produção em que eles vão trabalhar pelo resto da carreira. Sem reescrita. Sem substituição. Apenas responsabilidade de cuidar do que existe.
Então pergunte: o que eles consertariam primeiro para tornar o dia a dia no código melhor? Que frustrações finalmente resolveriam? O que deixariam de tolerar?
As respostas raramente têm a ver com frameworks. Elas falam de clareza, segurança e de reduzir estresse desnecessário. E, na maioria das vezes, essas respostas acabam sendo um roteiro melhor do que qualquer proposta de reescrita.
Uma última mudança de perspectiva
Deixar uma possível reescrita do software “em aberto” não é uma posição neutra.
Isso molda comportamento. Diminui padrões. Ensina equipes a postergar.
Faça a pergunta da reescrita. Leve-a a sério. Faça a análise. Mas quando decidir permanecer com o sistema atual, diga isso em voz alta. Registre o motivo. Reforce a decisão. Mostre o que melhorou desde então.
O que paralisa equipes não é software antigo. São futuros não resolvidos.
E o segundo ato não começa com código novo. Começa quando líderes ajudam suas equipes a retomar o controle dos sistemas dos quais já dependem todos os dias.
FAQ’s
Falar de reescrita é sempre um mau sinal?
Não. Fazer a pergunta é saudável. O problema é deixá-la sem resposta. Clareza importa mais do que a resposta em si.
Existe algum podcast que você recomenda sobre esse tema?
Sim. Maintainable explora exatamente essas questões em conversas com pessoas responsáveis por softwares que precisam durar.
A IA pode tornar reescritas mais seguras ou baratas agora?
A IA pode acelerar o início do trabalho, mas não remove as partes mais difíceis de uma reescrita: complexidade do domínio, migração de dados e execução de sistemas em paralelo.
Qual é a alternativa à reescrita?
Tratar o sistema existente como algo que vale a pena evoluir, melhorar as condições de trabalho da equipe, reduzir fricções e recuperar o ritmo passo a passo.