Dívida técnica não aparece em nenhum relatório financeiro. Aparece na velocidade de entrega que diminui a cada sprint sem que ninguém consiga explicar por quê.
O termo “dívida técnica” foi cunhado em 1992 por Ward Cunningham, um dos 17 autores do Manifesto Ágil e criador do conceito de wiki. Trabalhando no sistema WyCash, ele usou a metáfora financeira para explicar a stakeholders não-técnicos por que o time precisava reservar tempo para refatoração. Código entregue rápido funciona, dizia ele, mas é como tomar empréstimo: gera juros que precisam ser pagos depois.
A metáfora pegou porque é precisa. Toda decisão técnica tomada com pressa, ou com conhecimento incompleto, cria dívida. Algumas são inevitáveis. O prazo não permite a solução ideal, e o time avança com o que tem. Outras são resultado de falta de padrão, de documentação ausente, ou de código que funcionou e nunca mais foi revisitado.
A dívida técnica não é problema enquanto é pequena e localizada. Torna-se problema quando se acumula ao ponto de tornar qualquer mudança cara e arriscada.
O sinal mais comum é a percepção de que o time está “sempre ocupado, mas entregando menos”. Cada nova feature exige entender e contornar código antigo. Cada bug corrigido abre espaço para dois novos, em partes do sistema que ninguém esperava que fossem afetadas.
Outro sinal: o medo de mudar. Quando nenhum desenvolvedor do time quer mexer em determinado módulo porque “pode quebrar outras coisas”, esse módulo é dívida ativa. O custo não é só técnico. É cultural. O time aprende a evitar partes do sistema em vez de melhorá-las.
Martin Fowler, em 2009, formalizou uma distinção útil para entender essa dinâmica. Ele propôs o que chamou de “quadrante da dívida técnica”, que combina duas dimensões: a dívida pode ser deliberada ou inadvertida (o time sabia que estava tomando atalho, ou descobriu depois), e pode ser prudente ou imprudente (havia plano para pagar a dívida, ou não havia). A pior combinação é a dívida imprudente e inadvertida: foi feita errado, ninguém percebeu na hora, e ninguém vai pagar de volta. A melhor é a deliberada e prudente: foi feita rápido conscientemente, com plano de quando e como será refatorada.
A maioria dos times convive com os dois tipos sem distinguir. E é a distinção que abre caminho para tratar a dívida de forma diferente.
A decisão de deixar para refatorar depois é racional no curto prazo. O problema é que o “depois” raramente chega. Há sempre uma nova feature prioritária, um prazo que não pode escorregar, um cliente esperando.
O resultado é que a dívida cresce de forma composta. Código ruim sobre código ruim. Abstrações construídas sobre abstrações que não deveriam existir.
Daí a importância da distinção que Fowler propõe: a dívida prudente tem plano de pagamento desde o momento em que é contraída. Vai pra backlog, com prioridade, e é revisitada. A dívida imprudente fica órfã. E dívida órfã rende juros até ser impagável.
Times que controlam dívida técnica de forma consistente fazem três coisas que times que não controlam raramente fazem.
Primeiro, reservam capacidade para ela. Não como projeto separado, mas como parte regular do trabalho, uma proporção fixa de cada sprint dedicada a melhorias internas. Dez ou vinte por cento não é desperdício. É manutenção preventiva.
Segundo, definem padrões antes de precisar deles. Convenções de código, estrutura de pastas, como nomear variáveis, como estruturar um componente. Documentação que existe antes de o time crescer é infinitamente mais eficaz do que tentar documentar retroativamente.
Terceiro, tornam a dívida visível. Não basta saber que ela existe. Times que conseguem pagar dívida técnica costumam ter uma lista explícita, com itens priorizados, prazos estimados, e visibilidade pro produto e pra liderança. Dívida invisível não compete por capacidade com features novas. Sempre perde.
Em projetos de plataforma que vão evoluir ao longo de anos, a dívida técnica é tratada como parte do escopo desde o início, não como problema que aparece depois. Isso significa, na prática, reservar capacidade pra melhorias internas em cada ciclo, manter padrões documentados antes do código crescer, e classificar abertamente quando uma decisão técnica está sendo tomada como dívida deliberada e prudente, com plano de retorno.
Não é processo perfeito. Toda plataforma acumula alguma dívida ao longo do tempo. Mas a diferença entre acumular dívida controlada e acumular dívida invisível é a diferença entre uma plataforma que continua evoluindo ao longo de dez anos e uma plataforma que precisa ser refeita depois de três.
Referências consultadas: Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA Conference (1992); Martin Fowler, “Technical Debt Quadrant”, martinfowler.com (2009).
Acessibilidade não é só obrigação legal. É a diferença entre uma plataforma que funciona para todos e uma que exclui parte do mercado silenciosamente.
A escolha de tecnologia para um projeto digital não começa pela tecnologia. Começa pela pergunta certa: o que essa plataforma precisa fazer?
36% das empresas gastam mais tempo resolvendo problemas de APIs do que desenvolvendo funcionalidades. O problema quase nunca é a API. É a documentação tratada como anexo, não como produto.
