[Code Smell #6] Dívida técnica: o significado original de Cunningham

Resposta principal: dívida técnica é um termo criado por Ward Cunningham em 1992. Originalmente, significava a diferença entre o código e o entendimento atual, não código desorganizado.

Cunningham enfatizou que uma estratégia de dívida só funciona quando o código é limpo.

Existe um termo que desenvolvedores usam ao explicar refatoração para não desenvolvedores: dívida técnica.

Este texto dá continuidade ao artigo anterior, Code Smell #5.

A ideia é que contraímos uma dívida para construir rápido, os juros estão aumentando e precisamos de tempo para pagar.

Mas a pessoa que criou o termo afirmou várias vezes que sua metáfora estava sendo usada de forma errada, especialmente quando código desorganizado era chamado de dívida.

Ward Cunningham, 1992

Ward Cunningham usou a expressão dívida técnica pela primeira vez em 1992, em um relato de experiência para a OOPSLA (Object-Oriented Programming, Systems, Languages & Applications, conferência de programação orientada a objetos) (Artigo).

É o mesmo Cunningham conhecido por inventar a wiki e por ser uma figura dos primeiros anos da programação extrema.

Na época, ele desenvolvia software financeiro. A dificuldade estava no domínio.

Não é possível compreender exatamente a estrutura de produtos financeiros antes de começar. Por isso, ele escolheu construir e lançar o que entendia naquele momento e incorporar continuamente ao código o que aprendia com o uso.

A dívida de que ele falava surge aqui: a diferença entre o entendimento contido no código atual e o entendimento que a equipe realmente tem agora.

Uma estrutura correta quando foi escrita pode deixar de fazer sentido quando o domínio é mais bem compreendido. Isso é dívida; adaptar o código ao novo entendimento é o pagamento.

Em 2009, ele deixou um vídeo curto explicando a metáfora novamente e corrigindo o mal-entendido. O ponto era este (Debt Metaphor).

Contrair dívida é uma estratégia para aprender rápido, não uma permissão para escrever código ruim. Na verdade, uma estratégia de dívida só funciona quando o código é limpo.

Se o código está desorganizado, incorporar o que foi aprendido se torna impossível.

Este é o ponto central: no conceito original, a dívida também surge em código bem escrito.

Ela aparece automaticamente quando nossa forma de entender o mundo muda com o tempo.

Por outro lado, grande parte do que hoje chamamos de dívida técnica é simplesmente código feito de qualquer jeito. Nos termos de Cunningham, isso está mais para bagunça do que para dívida.

O quadrante de Fowler

Ainda assim, dizer que “só dívida de verdade é dívida” torna o conceito difícil de usar na prática. O quadrante organizado por Martin Fowler em 2009 preenche bem essa lacuna (Technical Debt Quadrant).

Ele usa dois eixos: intencional ou inadvertida, e imprudente ou prudente.

	Imprudente	Prudente
Intencional	“Não há tempo para projetar”	“Vamos lançar agora e aceitar o custo”
Inadvertida	“O que é separação de camadas?”	“Agora entendi como deveria ter sido feito”

As quatro células têm características completamente diferentes.

Intencional·prudente é uma decisão de negócio. Existe um prazo, atrasar significa perder uma oportunidade e a escolha é feita sabendo que o custo virá depois.

É a célula em que a metáfora da dívida se encaixa com mais precisão.

Há uma condição: conhecer o custo.

Inadvertida·prudente é a dívida original de Cunningham. Você fez o melhor trabalho possível e, seis meses depois, ao entender melhor o domínio, percebeu uma estrutura melhor.

Ela surge mesmo quando ninguém fez nada errado. Como não pode ser evitada, a única resposta é estabelecer um ciclo de pagamento.

Intencional·imprudente significa fazer algo de qualquer jeito, sabendo disso. Costuma ser chamada de dívida, mas, sem um plano de pagamento, está mais próxima de uma perda.

Inadvertida·imprudente significa que aconteceu por falta de conhecimento. A solução aqui é aprender, não criar um cronograma de refatoração.

A resposta ao mesmo código desorganizado muda conforme a célula. Quando equipes se desencontram ao falar de dívida, muitas vezes estão imaginando células diferentes.

Com o que se pagam os juros?

Os juros da dívida financeira são dinheiro; os da dívida técnica são o custo de mudanças futuras. Se adicionar a mesma funcionalidade leva um dia sem dívida e três dias com ela, os dois dias extras são juros.

Essa definição leva a uma conclusão: a dívida de um código que ninguém toca tem juros zero.

Um módulo que ninguém altera há cinco anos pode estar muito desorganizado, mas, se ninguém vai alterá-lo no futuro, não há motivo para pagá-lo. Já uma pequena dívida em uma tela tocada toda semana continua gerando juros.

Muitas equipes ordenam a lista de dívidas por “o quanto isso é ruim”, mas o critério real deveria ser “com que frequência isso é alterado”.

A consulta de frequência de mudanças no Git usada no artigo anterior também é útil aqui. A interseção entre arquivos que mudam com frequência e arquivos de baixa qualidade é onde a taxa de juros é mais alta.

Adam Tornhill chama de análise de código baseada em comportamento a abordagem de encontrar essa interseção e priorizá-la.

Os limites da metáfora

O termo dívida técnica é conveniente, e esse é justamente o problema. Qualquer coisa pode ser colocada nele.

Bugs, bibliotecas antigas, designs de que você não gosta e código que não foi escrito por você: tudo vira dívida. A palavra então se torna sinônimo de “coisas que quero corrigir” e perde seu poder explicativo original.

É prático chamar algo de dívida apenas quando ele passa por duas perguntas.

1. **O que você ganhou ao contraí-la?**Você precisa conseguir dizer se ganhou tempo ou aprendizado. Se não ganhou nada, não é dívida, mas um erro.
2. **Como você vai pagá-la?**Uma dívida sem plano de pagamento não sustenta a metáfora.

Algumas pessoas também rejeitam a própria metáfora. A palavra dívida sugere que “um dia é possível pagar”, escondendo situações em que ela cresce com juros compostos até se tornar impossível de quitar.

Alguns sugerem chamar isso de contaminação ou problema de higiene, porque se parece mais com algo que precisa ser continuamente limpo do que com algo que pode ser pago.

Ainda assim, há um motivo para a palavra dívida ter sobrevivido tanto tempo: é uma das poucas metáforas que funcionam em conversas fora do desenvolvimento.

Cunningham usou a metáfora pela primeira vez ao explicar ao chefe a necessidade de refazer trabalho. Não é um termo preciso, mas continua valiosa como ferramenta de tradução.

Como gerenciar na prática

**Faça uma lista, mas não a esconda no issue tracker.**Um backlog composto apenas por tickets de dívida normalmente não é consultado por ninguém.

Em vez disso, deixe as informações perto do código. Anote brevemente no arquivo por que ele ficou assim e do que precisa; a próxima pessoa que o abrir verá isso.

**Pague enquanto estiver mexendo nele.**Quando você já vai alterar o arquivo, os juros estão sendo gerados e o contexto ainda está fresco na sua cabeça.

É por isso que a regra do escoteiro — “deixe mais limpo do que encontrou” — funciona de verdade como método de gestão da dívida.

**Decidir não pagar também é gerenciar.**Metade dos itens da lista de dívidas serve para registro, não para pagamento.

Decidir explicitamente não pagar um item evita repetir a mesma discussão no futuro.

**Ao contrair dívida intencionalmente, registre também a condição.**Por exemplo, “nas duas semanas após o lançamento” ou “antes de ultrapassar 10 mil usuários”.

Uma dívida contraída sem prazo também não tem data para ser paga.

Resumo

• Dívida técnica é um termo criado por Ward Cunningham em 1992. Originalmente, significava a diferença entre o código e o entendimento atual, não código desorganizado.
• Cunningham enfatizou que uma estratégia de dívida só funciona quando o código é limpo.
• O quadrante de Fowler divide as células por intencionalidade e prudência. Cada uma exige uma resposta diferente.
• Os juros são o custo de mudanças futuras. A dívida de um código que não é tocado tem juros zero, então não há motivo para pagá-la.
• Se você não consegue dizer o que ganhou nem como vai pagar, isso não é dívida, mas apenas um problema.

O próximo artigo aborda as opções quando a dívida se acumula além do que é possível administrar: corrigir e continuar usando ou reescrever do zero.

É também onde surgiram algumas das respostas erradas mais caras da indústria de software.

Fontes e critérios de verificação

• The WyCash Portfolio Management System — Ward Cunningham · Artigo original · Verificado em 2026-08-17 · Base: explicação original da metáfora de dívida técnica de 1992
• Debt Metaphor — Ward Cunningham · Texto original do autor · Verificado em 2026-08-17 · Base: explicação de Ward Cunningham, em 2009, sobre a metáfora de dívida técnica
• Technical Debt Quadrant — Martin Fowler · Texto original do autor · Verificado em 2026-08-17 · Base: quadrante de dívida técnica dividido por prudência, imprudência e intencionalidade

Continue lendo

Série Code Smell

• Artigo anterior: [Code Smell #5] Cirurgia de espingarda vs. mudança divergente
• Artigo anterior: [Code Smell #4] God Object: guia completo
• Artigo anterior: [Code Smell #3] Código ravioli: código cujo fluxo ninguém entende