O que é Dívida Técnica?

Ward Cunningham introduziu a metáfora da dívida no contexto de desenvolvimento de software em um relato apresentado na OOPSLA em 1992. A imagem ajudava a explicar por que uma implementação inicial pode permitir aprendizado e entrega, mas exige consolidação quando o entendimento do domínio melhora.

Martin Fowler ampliou o debate sobre tipos deliberados e inadvertidos de dívida e sobre os limites da analogia financeira. Seu texto esclarece que o custo extra costuma aparecer quando uma área do software precisa mudar; não cresce necessariamente a cada dia apenas pela passagem do tempo.

Imagine uma parte do sistema com regras duplicadas em quatro lugares. Uma mudança de política que poderia ser feita em um ponto exige localizar as cópias, alterar cada uma e testar se todas continuam coerentes. O trabalho extra é o juro da dívida. Refatorar para representar a regra uma vez pode reduzir esse custo futuro, mas também consome tempo agora. A decisão pede olhar para frequência de mudança, risco e benefício, não apenas para a aparência do código.

Nem toda dívida nasce de pressa. Um time pode escolher conscientemente uma solução limitada para testar uma hipótese e anotar quando revisá-la. Também pode descobrir depois que uma estrutura antes adequada não suporta novas necessidades. Mudança de biblioteca, de requisitos ou de conhecimento do domínio pode expor uma limitação. O importante é tornar o custo visível e escolher como lidar com ele.

A metáfora tem limites. Num empréstimo financeiro, os juros são cobrados segundo um contrato e calendário. Em software, uma área confusa pode ficar meses sem ser tocada, sem impor esforço de alteração nesse período. Outra pode mudar toda semana e consumir horas extras repetidas vezes. Segurança e obsolescência podem criar custos mesmo sem novas funcionalidades, pois exigem manutenção, resposta a vulnerabilidades ou migração de plataforma. Por isso, “toda dívida aumenta exponencialmente” é uma afirmação forte demais.

Localize o efeito. Em vez de escrever “código ruim” no Backlog, descreva a parte afetada, que mudanças ficaram lentas ou arriscadas e qual melhoria é proposta. Uma dependência antiga impede atualização de segurança? Uma suíte frágil exige verificação manual a cada release? Um módulo complexo gera defeitos quando toca determinada regra? A consequência conecta a conversa técnica ao resultado de produto.

Separe dívida de defeito e de hipótese futura. Um bug que impede comportamento acordado exige correção; uma estrutura difícil de manter pode ser dívida; um framework imaginado para uma necessidade que ainda não existe não é automaticamente dívida por não ter sido construído. A Definition of Done estabelece o padrão mínimo do Incremento. Chamar de “dívida” o trabalho que falta para cumprir a DoD não torna o item pronto no Scrum.

Priorize por risco e frequência. Uma parte muito alterada e com alto custo de mudança merece atenção próxima. Uma parte estável pode esperar, desde que segurança e operação estejam adequadas. Algumas melhorias cabem em refatorações pequenas ao tocar a área; outras exigem iniciativa planejada e coordenação com produto. Decidir não pagar agora pode ser racional se a consequência for compreendida e monitorada.

Evite a falsa troca entre qualidade e velocidade. Remover testes ou revisão para terminar hoje pode atrasar a própria entrega se defeitos e retrabalho aparecerem imediatamente. Por outro lado, exigir arquitetura para todas as possibilidades imagináveis pode consumir meses antes de aprender com usuários. A escolha prudente preserva o necessário para mudar com segurança e adia o desenho que ainda não tem justificativa.

Práticas como TDD, pair programming e CI/CD podem ajudar a manter feedback sobre qualidade, mas nenhuma ferramenta impede automaticamente dívida. Um sistema com testes pode ter uma modelagem difícil de evoluir; um pipeline rápido pode entregar defeitos rapidamente. Observe o custo real de mudar e a qualidade do produto, não apenas a presença de práticas.

O Product Owner pode ajudar a ordenar melhorias ao entender seu impacto sobre valor, risco e próximas entregas. Os Desenvolvedores explicam consequências técnicas e opções. Essa colaboração evita dois extremos: esconder trabalho técnico como se não tivesse custo, ou tratá-lo como pedido de tempo sem relação com o produto. A discussão deve incluir quando o benefício será percebido e como verificar se a melhoria reduziu atrito.

Imagine um sistema hipotético de inscrições que usa uma biblioteca antiga. A equipe consegue entregar novas telas, mas uma atualização de segurança exige migrar a integração. Nos 3 meses anteriores, cada alteração naquela área levou cerca de 5 dias, dos quais 2 foram usados em testes manuais e ajustes decorrentes da dependência. Os números são apenas do exemplo.

Antes, o time trata cada atraso como caso isolado e mantém a migração fora da conversa de produto. Quando surge uma exigência de segurança, o trabalho precisa ser feito com pressa e risco. Depois, registra a dependência, os custos observados e as opções: migrar tudo de uma vez, criar uma camada que permita troca gradual ou reduzir primeiro os passos manuais de teste. Discute com responsáveis por segurança e produto o risco de cada caminho.

O grupo escolhe uma migração incremental em 4 partes, com testes de integração que cubram as regras essenciais. A primeira parte custa mais do que uma alteração comum, mas reduz incerteza sobre o restante. Após concluir a mudança, compara o tempo de futuras alterações e a frequência de incidentes. Se não houver novas mudanças naquela área, talvez não seja possível demonstrar economia imediata em prazo; o risco de segurança, porém, também fazia parte da decisão.

Este cenário mostra por que pagar dívida não é simplesmente “limpar código”. É escolher um investimento técnico com uma consequência esperada, reconhecer incerteza e verificar depois se o sistema ficou mais seguro ou mais fácil de alterar. Um exemplo semelhante pode surgir num processo de dados, numa configuração manual ou numa integração que poucas pessoas compreendem.

Curso K21 recomendado