O verdadeiro motivo de sua equipe de engenharia estar lenta não são as pessoas, e sim a base de código

• Codebase Drag é o estado de uma base de código em que tudo leva mais tempo do que deveria, e como isso não aparece em dashboards ou relatórios de sprint, a liderança entra num ciclo de interpretá-lo erroneamente como um “problema de pessoas”
• Após anos de auditorias de base de código, os mesmos 5 sinais apareceram repetidamente, e é proposto um diagnóstico quantitativo, a “auditoria de arrasto da base de código”, que os pontua de 0 a 2
• Inchar estimativas, medo de deploy, arquivos “não mexa nisso”, a mentira da cobertura e o tempo até o primeiro commit: esses 5 sinais vêm todos de problemas de qualidade da base de código e se diferenciam da falta de habilidade das pessoas
• Quanto mais experiente é o engenheiro, melhor ele percebe os riscos da base de código e mais cauteloso se move, o que gera o paradoxo de parecer ainda mais lento; quando isso é confundido com problema de talento, o efeito colateral é adicionar apenas mais processo
• Com 4 pontos ou mais, é preciso investir diretamente na base de código; com 7 pontos ou mais, o nível exige intervenção estrutural imediata

---

O que é Codebase Drag

• Codebase Drag é o fenômeno em que a base de código faz com que todo trabalho leve mais tempo do que deveria, e isso não aparece em relatórios de sprint nem em dashboards
  • Exemplo: a equipe cliente gastou 1 semana com 2 engenheiros para adicionar exportação de CSV ao painel administrativo — o trabalho em si era de um dia, mas o restante do tempo foi gasto entendendo como modificar o código existente com segurança
• Quando a queda de velocidade do time se repete, a liderança julga que é um problema de talento e responde com reorganização, mais processo ou troca de pessoas, mas a equipe seguinte esbarra na mesma parede
• A raiz do problema não são bugs, nem funcionalidades faltando, nem a dívida técnica no sentido mais comum, mas sim a própria base de código

5 sinais de arrasto da base de código

1. Estimativa de desculpa (Apology Estimate)

• Situação em que um engenheiro estima 2 semanas para uma funcionalidade que na prática levaria 3 dias, e a liderança interpreta isso erroneamente como inflar o cronograma
• O motivo real é o acoplamento entre módulos — mexer no módulo de billing também afeta o sistema de notification — e uma estrutura em que não dá para saber até onde o impacto da mudança vai
  • Por causa de default scope oculto ou callbacks profundamente aninhados, é impossível prever o raio de impacto (blast radius) sem ler metade do código
• Se as estimativas consistentemente levam de 2 a 3 vezes mais tempo que o esperado, o problema não é estimativa, e sim custo da base de código

2. Medo de deploy (Deploy Fear)

• Aparece quando o time evita deploys na sexta-feira ou agrupa deploys em lotes grandes e libera com pouca frequência
• Uma equipe cliente operava com uma regra informal de não fazer deploy depois de quarta-feira — prática criada depois que 3 deploys feitos na quinta resultaram em incidentes no fim de semana
  • As causas eram ausência de estratégia de rollback, testes não confiáveis e um pipeline de deploy de 45 minutos
• Segundo o DORA, equipes elite mantêm taxa de falha de mudança abaixo de 5% e fazem deploy imediatamente quando necessário, mas essa equipe vivia no estado de fazer deploy uma vez por semana, esperando apreensiva

3. O arquivo “não mexa nisso” (Don't Touch That File)

• Em quase todo lugar, a frase “não mexa naquele arquivo” aparece nos primeiros dois dias
  • Um controller de billing com 30 before_action, ou um model que aparece no topo do git log, mas estruturalmente não é tocado de verdade há anos
• Ao rodar git log --oneline --since="2 years ago", o arquivo mais alterado é sempre aquele que todos avisaram sobre ele — se só há pequenos patches repetidos e nenhum trabalho estrutural, estão tratando sintomas e deixando a doença
• O custo real é que funcionalidades que deveriam estar nesse módulo passam a ser implementadas em outros lugares, e novos contratados aprendem já na primeira semana a evitá-lo — a base de código cresce de forma deformada em torno de zonas mortas

4. A mentira da cobertura (Coverage Lie)

• O número de 80% de cobertura de testes parece saudável, mas na prática ele costuma ser sustentado por testes de serializer, helper e utilitários que quase nunca quebram, enquanto os 3 principais models que lidam com dinheiro não têm teste nenhum
• A suíte de testes existe não para pegar regressões, mas para fazer a métrica parecer boa — os testes passam e a produção quebra do mesmo jeito
• Como o CI leva 40 minutos, os desenvolvedores param de rodar testes localmente → a métrica de cobertura mente em dois sentidos: não cobre as partes importantes e nem mesmo os testes existentes são executados
• A pergunta real não é o número de cobertura, mas sim “quando foi a última vez que um teste pegou um bug antes de ele chegar à produção?”

5. Tempo até o primeiro commit (Time to First Commit)

• É o tempo entre entregar um notebook a um novo engenheiro e ele abrir um PR com correção de bug real ou pequena funcionalidade
  • Base de código saudável: 1 a 2 dias
  • Base de código com arrasto: mais de 2 semanas
• Um cliente levava semanas para configurar o ambiente de desenvolvimento, mas após correções um novo desenvolvedor passou a concluir a configuração em 15 a 20 minutos
• A causa central é a deterioração do setup (setup rot) — o script bin/setup não foi atualizado desde a última mudança de ambiente, os dados de seed referenciam tabelas e colunas que já não existem, e há 3 variáveis de ambiente não documentadas que só são descobertas quando a aplicação falha ao subir
• Como os engenheiros antigos já internalizaram procedimentos não documentados, apenas os novos contratados revelam com precisão o tamanho do conhecimento implícito exigido pela base de código

Por que bons engenheiros parecem lentos em uma base de código ruim

• Os 5 sinais agem em conjunto e adicionam overhead a todo trabalho sem que seja algo facilmente apontável numa standup
  • Um engenheiro que no emprego anterior implementava uma funcionalidade em dois dias leva uma semana nessa base de código, e quando tenta explicar o motivo soa como desculpa
• Um estudo da METR de 2025 mostrou que desenvolvedores experientes ficaram 19% mais lentos ao usar ferramentas de IA — evidência de que o gargalo não era digitação
• Quanto melhor o engenheiro, melhor ele percebe o risco e mais cauteloso age, fazendo estimativas mais folgadas — um engenheiro menos experiente não enxerga o risco, faz deploy mais rápido, causa incidente em produção e acaba deixando o time inteiro ainda mais cauteloso
• Um cliente trocou 6 equipes em 10 anos (incluindo 2 aquisições completas) — repetindo o padrão: exigência da liderança por features → pular o tratamento da dívida → código chegar a um estado irrecuperável → propor rewrite ou separar em microsserviços → o sistema dobrar de tamanho e piorar ainda mais
• Quando a liderança lê a lentidão como problema de talento, só adiciona mais processo a um time já sofrendo com atrito, piorando a situação — a única intervenção realmente útil é corrigir o próprio caminho

Auditoria de arrasto da base de código: como diagnosticar

• Dê uma nota de 0 a 2 para cada um dos 5 sinais:
  • 0 pontos: sem problema
  • 1 ponto: problema parcial
  • 2 pontos: problema grave
• Com 4 pontos ou mais, investir diretamente na base de código deve vir antes de qualquer outra medida

Como reagir quando a dívida técnica passa a frear o time

• Comece pelo sinal com a maior pontuação — não tente consertar tudo ao mesmo tempo
  • Medo de deploy com nota 2: priorize velocidade do CI, automação de rollback e melhoria no tamanho dos lotes de deploy
  • Estimativa de desculpa em 1º lugar: priorize desacoplar os módulos com maior blast radius
  • Tempo até o primeiro commit com nota 2: investir um dia para corrigir bin/setup e documentar o ambiente pode ser recuperado em todas as futuras contratações
• Se o Rails estiver várias versões atrasado, um upgrade de versão pode funcionar como forcing function para justificar o investimento
• Meça em ciclos de 2 semanas: escolha o sinal com maior nota → sprint focado → medir números concretos (frequência de deploy, precisão das estimativas, tempo até o primeiro PR etc.)
• O motivo de ser difícil aprovar esse investimento é que o custo de não fazer nada é invisível — dizer “temos dívida técnica” é muito menos convincente do que dizer “o acoplamento desses três módulos faz toda funcionalidade levar quase o dobro do tempo”
• 7 pontos ou mais normalmente indicam um nível em que se começa com uma auditoria da base de código de 1 semana

[mbh023]

Real oficial, projeto legado é um câncer.
Tem coisa que nem vale mais a pena mexer, é melhor refazer do zero.

[hanje3765]

Parece que estou falando de mim...?

[maedk10]

Parece ser um texto realmente importante para reduzir os custos de manutenção.

[cronex]

É por isso que às vezes reescrever do zero acaba sendo mais rápido.

[kallare]

Todo mundo sabe que organizar o codebase é, no longo prazo, o caminho para ganhar velocidade,
mas é o mesmo tipo de história de dizer que comer bem, se exercitar e dormir direito faz bem para a saúde.