Seu time entregava uma feature por semana e hoje leva três para a mesma coisa. A causa é a dívida técnica acumulada sprint a sprint, decisão a decisão, até o custo de entrega passar do ponto em que alguém lembra onde o problema começou.
A metáfora de Ward Cunningham
Ward Cunningham apresentou a ideia em 1992, no relato do sistema WyCash: escolher a solução simples agora e devolver o tempo depois, com juros, na refatoração. Dívida boa existe e paga retorno quando o produto cresce.
A maior parte da dívida que você carrega é acidental. Ninguém decidiu ela. Ela entra por decisão apressada, por prazo fechado sem acompanhamento, por código que ninguém mexeu por três anos.
Três tipos aparecem no dia a dia:
- Dívida deliberada: "Fazemos assim agora, arrumamos depois." O depois raramente chega.
- Dívida inadvertida: o design certo aparece só depois do código pronto, e o time corrige quando o prazo permite.
- Dívida entrópica: o sistema funciona e ninguém sabe por quê. O documento sumiu, o autor foi embora, o time não toca no módulo.
A entrópica não aparece em backlog nenhum. Ela cobra quando algo quebra, e a conta chega com investigação junto. Michael Feathers descreve esse módulo intocável em Working Effectively with Legacy Code (Prentice Hall, 2004).
Como a dívida cobra a velocidade
Três gatilhos fazem o serviço. O engenheiro lê o sistema complexo antes de mexer e perde dias entendendo o caminho. Mudança em A quebra B, porque os módulos conversam por efeito colateral. Ninguém assume a mudança que pode derrubar produção, e a fila de decisão cresce.
Na prática, o time gasta três semanas descobrindo onde a feature se conecta e mais duas garantindo que nada ao redor quebrou.
A curva é conhecida: velocidade alta nos primeiros meses, queda a cada trimestre sem investimento em qualidade. Depois de dois ou três anos, as novas features carregam tanta estabilização que o produto para. Forsgren, Humble e Kim medem o efeito em Accelerate (2018): entrega rápida acompanha automação de deploy, teste confiável e trabalho planejado em qualidade.
Dívida técnica é assunto de negócio
CTO que arquiva dívida como assunto de engenharia perde a conversa de orçamento. O custo direto aparece em cinco lugares:
- Horas de engenharia por feature entregue
- Bugs em produção e o custo de corrigi-los
- Engenheiros que saem em vez de manter sistema ruim
- Resposta lenta a oportunidade de mercado
- Incidentes maiores conforme o sistema fica mais frágil
Traduza cada linha em horas e reais, e a conversa com a diretoria muda de tom.
Três formas de medir o que você deve
Mapa de pontos de dor
Pergunte ao time qual área dá medo de mexer. As respostas marcam os módulos que já custam caro. Área que todo engenheiro evita é área com dívida ativa.
Tempo de ciclo por área
Compare o tempo médio de entrega em cada parte do sistema. O trecho que demora o triplo é onde o time perde dias a cada pedido.
Bugs por módulo
Módulo com bug acima da média costuma ter acoplamento alto e teste baixo. Aumente a cobertura desse módulo antes de refatorar o resto.
O que pagar primeiro
Dívida em sistema legado que ninguém usa fica parada. Dívida na API que processa 80% do volume entra na frente, seja qual for o custo.
Reserve de 15% a 20% da capacidade de engenharia para refatoração, teste, documentação e atualização de dependência. A reserva vira prática de todo sprint; projeto único não muda a curva. Martin Fowler trata do trabalho contínuo em Refactoring, 2ª edição (Addison-Wesley, 2018).
Time que não reserva esse espaço chega em 18 a 24 meses no projeto de reescrita, com escopo e prazo subestimados.
Diagnóstico antes de qualquer refatoração
Quando a entrega caiu e a complexidade acumulada é a suspeita, você pede um levantamento honesto: quanto de dívida existe, onde ela se concentra, quanto custa carregar e quanto custa pagar.
O levantamento devolve número, dívida em reais por área. Com o número na mesa, você decide o que paga neste trimestre e o que adia para o próximo.
