A metáfora foi cunhada por Ward Cunningham, um dos pais do desenvolvimento ágil, e é a mais precisa da engenharia de software: atalhos no código são como dívida financeira. Tomar dívida pode ser inteligente (chegar antes ao mercado, validar uma hipótese), desde que se conheça a taxa de juros. O problema nunca é a dívida; é a dívida invisível, sem gestão, cujos juros são pagos em cada sprint sem ninguém contabilizar.

Os juros aparecem assim

• A feature que levava 3 dias passa a levar 2 semanas, "porque tem que mexer naquele módulo".
• Todo deploy quebra algo em lugar inesperado.
• Só uma pessoa consegue mexer em certa parte do sistema (e ela quer férias).
• Estimativas viram chute com pedido de desculpas.
• Onboarding de dev novo leva meses em vez de semanas.

Nada disso aparece na demo do sprint. Tudo isso aparece no custo por feature, que é onde a conversa com o negócio deveria acontecer.

Nem toda dívida é pecado: o quadrante de Fowler

Martin Fowler organizou o assunto num quadrante que vale decorar (Technical Debt Quadrant): a dívida pode ser deliberada ou inadvertida, prudente ou imprudente.

• Deliberada e prudente: "vamos lançar simples agora e refatorar quando validar". Dívida estratégica, com registro e plano. Saudável.
• Deliberada e imprudente: "não temos tempo para fazer direito" como cultura permanente. A fatura chega com juros compostos.
• Inadvertida e prudente: "agora que aprendemos, faríamos diferente". Inevitável em qualquer produto que evolui; é aprendizado com forma de código.
• Inadvertida e imprudente: ninguém sabia o que estava fazendo. O caso que treinamento e revisão de código previnem.

A pergunta de gestão não é "temos dívida?" (todo mundo tem), e sim "sabemos qual é, onde está e quanto custa?".

Como medir sem virar filosofia

Esqueça o número único e perfeito; use sinais convergentes:

1. Hotspots (o cruzamento que vale ouro): código que muda muito E é complexo é onde os juros se concentram. O histórico do git dá a frequência de mudança; qualquer ferramenta de análise dá a complexidade. O top 10 desse cruzamento é seu mapa de pagamento, e costuma ser surpreendentemente pequeno.
2. Tendência do lead time: o tempo entre começar e entregar uma feature está subindo trimestre a trimestre? Os juros estão subindo.
3. Taxa de retrabalho: percentual de bugs e correções sobre o total entregue.
4. A pergunta ao time: "onde dói mexer?" Engenheiro sabe exatamente onde a dívida mora; ninguém pergunta.

Quando (e como) pagar

Pague onde você trabalha. A regra do escoteiro: o código por onde a roadmap vai passar merece a limpeza antes; o módulo estável que ninguém toca há dois anos pode esperar para sempre. Dívida em código morto não cobra juros.

Reserve um percentual contínuo, não um "sprint de limpeza" anual. Times saudáveis dedicam algo como 15-20% da capacidade à saúde do código, como manutenção de fábrica. O mutirão anual é o equivalente a só escovar os dentes na véspera do dentista.

Atrele ao valor, não à estética. "Refatorar o módulo de pedidos" não convence ninguém. "Reduzir o tempo de entrega de features de pagamento de 2 semanas para 3 dias" é investimento com retorno. A dívida se prioriza como qualquer item de backlog: por impacto.

Registre a dívida nova no ato. Tomou o atalho conscientemente? Vira item registrado com contexto, como uma decisão de arquitetura. Dívida documentada é gerenciável; dívida na memória de alguém é bomba-relógio.

O que não fazer

Não anuncie falência sem auditoria: a grande reescrita raramente é a resposta (e é o tema do terceiro artigo desta série). Reescrever tudo por causa de dívida difusa costuma trocar juros conhecidos por riscos desconhecidos.

Transforme a fatura invisível em plano

Esse diagnóstico (hotspots, métricas de tendência e o plano de pagamento atrelado à roadmap) é o ponto de partida do nosso serviço de Manutenção e Evolução.

Quer saber onde seus juros se concentram? Diga à IA da Rabelo Digital, aqui no canto da tela, qual módulo seu time evita tocar. Ela monta o raciocínio do diagnóstico. Sem formulário, sem espera.

---

Leia também

• Refatoração sem medo
• Reescrever ou evoluir? Como decidir