ARTIGO · DIAGNÓSTICO TÉCNICO

Débito técnico ou dívida técnica: qual é o termo certo, o que significa e como medir

As duas formas circulam no Brasil e nenhuma norma decide. Mais importante que o nome é o que a metáfora original dizia — e o que as ferramentas de medição conseguem, e não conseguem, capturar.

Ver consultoria

Por Carlos Eduardo de Souza Soares · CTO da Avia Hub

Publicado em 5 de setembro de 2026. Revisamos este texto quando a fonte citada muda.

Qual é o termo certo

As duas formas estão corretas em português e nenhuma fonte normativa decide entre elas. Procuramos norma da ABNT, glossário de universidade e glossário de órgão público, e não encontramos definição oficial.

O que dá para verificar é o uso. Na produção acadêmica brasileira da Sociedade Brasileira de Computação, predomina “dívida técnica” — é a forma dos trabalhos apresentados no Simpósio Brasileiro de Qualidade de Software. Em conteúdo técnico de mercado, “débito técnico” tem forte presença. Há inclusive trabalho acadêmico que usa “débito técnico” no título e “dívidas técnicas” no resumo.

Nossa preferência é “débito técnico”, e a razão é de registro: em conversa de orçamento, “dívida” carrega uma carga de culpa que atrapalha a discussão técnica. Mas se o seu time diz “dívida técnica”, está igualmente certo. O termo em inglês é technical debt, e é ele que você deve buscar para achar a literatura.

O que a metáfora original realmente dizia

O termo vem de Ward Cunningham, num relato de experiência de 1992 sobre um sistema de gestão de carteira financeira. O texto é curto e vale a citação literal:

“Entregar código de primeira versão é como contrair dívida. Um pouco de dívida acelera o desenvolvimento desde que seja paga prontamente com uma reescrita. O perigo ocorre quando a dívida não é paga. Cada minuto gasto em código não-exatamente-certo conta como juro dessa dívida. Organizações inteiras de engenharia podem ser levadas à paralisia sob a carga de dívida de uma implementação não consolidada.”

Três coisas nesse parágrafo costumam se perder na tradução para o dia a dia.

A primeira: contrair a dívida é apresentado como uma decisão que acelera. Não é erro — é alavancagem. O erro é não pagar.

A segunda: o juro não é uma multa futura. É o tempo perdido agora, a cada alteração, por causa do desalinhamento entre o que o código faz e o que hoje se entende como certo.

A terceira: Cunningham voltou ao assunto anos depois para esclarecer que a dívida não era escrever código ruim. Era escrever código que não refletia o entendimento atual do problema — e por isso obrigava a equipe a tropeçar naquele desalinhamento a cada mudança. Código sujo por descuido não é a dívida original; é outra coisa, pior, porque nem sequer foi uma decisão.

O quadrante: nem toda dívida é igual

Martin Fowler propôs, em 2009, separar os casos em dois eixos: a decisão foi deliberada ou inadvertida, e foi prudente ou imprudente. O cruzamento dá quatro situações muito diferentes entre si, que costumam ser tratadas com a mesma palavra.

	Prudente	Imprudente
Deliberada	A equipe sabe qual é o desenho correto, escolhe conscientemente entregar antes e registra o que ficou para depois. É alavancagem — a dívida do texto de 1992.	A equipe sabe qual é o desenho correto e entrega mal mesmo assim, sem registro e sem prazo. É a que vira paralisia.
Inadvertida	Só depois de construir a equipe entende qual era o desenho certo. Fowler considera esse caso inevitável em qualquer projeto sério.	A equipe não sabia que existia um desenho melhor. Não é decisão: é falta de base técnica, e se resolve com pessoas, não com refatoração.

A utilidade prática do quadrante é de conversa. Quando alguém diz “temos muita dívida técnica”, a pergunta seguinte é: de qual das quatro? Porque três delas têm tratamentos diferentes, e uma delas nem é problema de código.

Uma ressalva de honestidade: as legendas que circulam pela internet dentro da imagem do quadrante de Fowler não estão em texto na página original e não conseguimos confirmá-las. Descrevemos as quatro casas pelos eixos, que esses sim estão no texto.

Como medir

Existem três caminhos, e eles medem coisas diferentes.

1. Norma sobre o código. A ISO/IEC 5055, de 2021, mede quatro características a partir do código-fonte — confiabilidade, segurança, eficiência de desempenho e manutenibilidade — detectando e contando violações de boas práticas de arquitetura e codificação. É a base mais próxima de um padrão neutro que existe hoje.

2. Custo de remediação. O método SQALE calcula a distância até a conformidade pelo custo de trazer o código à conformidade. É esse modelo que está por trás da métrica que a maioria das equipes vê na prática, no SonarQube: o esforço de remediação em minutos, e a razão entre esse esforço e o custo de ter desenvolvido o código.

Um detalhe dessa fórmula merece atenção. O denominador usa um custo por linha de código, e o valor padrão do produto é 30 minutos por linha. Esse número é um parâmetro de configuração, não uma constante empírica. Quando alguém apresenta “nosso débito técnico é 6%”, esse 6% está calibrado por uma convenção do fornecedor da ferramenta. Não é errado — mas não é uma grandeza física.

3. Perguntar a quem escreve o código. É o caminho menos glamouroso e, pela única evidência independente que encontramos, o mais informativo.

O que a medição automatizada não captura

Este é o achado mais importante do levantamento que fizemos para este texto, e ele contraria o que se costuma vender.

Uma equipe de pesquisa do Google publicou, em 2023, um estudo sobre como definir, medir e gerenciar débito técnico internamente. A conclusão foi direta: nenhuma métrica isolada previu os relatos de débito técnico feitos pelos próprios engenheiros. Os modelos de regressão linear explicaram menos de 1% da variação nas respostas. Modelos mais sofisticados chegaram a boa precisão, mas com baixa cobertura.

Traduzindo: as propriedades do código que as ferramentas medem não predizem o atrito que a equipe efetivamente sente ao trabalhar naquele código.

Vale notar de onde vem cada número. As três fontes mais citadas para dimensionar o custo do débito técnico têm interesse comercial no diagnóstico: o consórcio que estimou US$ 1,52 trilhão de débito acumulado nos Estados Unidos tem, entre seus patrocinadores fundadores, uma fornecedora de ferramentas de medição; o relatório que estimou 17,3 horas semanais por desenvolvedor é de uma empresa que vende infraestrutura para desenvolvedores, e as horas são estimativa de percepção de executivos sobre o tempo de terceiros, não medição; e a pesquisa que apontou débito equivalente a 20% a 40% do patrimônio tecnológico é de uma consultoria que vende modernização, com amostra de 50 CIOs de grandes empresas de dois setores.

Nenhum desses números é falso. Todos são úteis para dimensionar ordem de grandeza. Mas a única fonte sem conflito comercial que mediu o fenômeno com rigor concluiu que a medição automatizada não captura o que importa — e essa é uma informação que quem vende medição não tem incentivo para destacar.

Como priorizar o que pagar

A orientação mais útil que conhecemos é geográfica, não cronológica, e vem do próprio Fowler: pague onde o código muda, ignore onde ele está parado.

“Se existe uma área terrível do código, que é um pesadelo para alterar, isso não é problema enquanto eu não precisar alterá-la. Áreas ruins mas estáveis do código podem ser deixadas em paz. Em contraste, áreas de alta atividade exigem uma atitude de tolerância zero.”

Isso inverte a lógica de quem prioriza pela nota da ferramenta. O módulo com a pior pontuação pode ser o que ninguém toca há três anos — e nesse caso a pontuação não custa nada à empresa. O módulo que merece atenção é aquele em que a equipe mexe toda semana, mesmo que a nota dele seja média.

Na prática, isso significa cruzar duas informações que quase nunca estão na mesma tela: a medição de qualidade do código e a frequência de alteração de cada arquivo, que está no histórico do versionamento. Onde as duas se sobrepõem é onde o juro está sendo pago.

O que isso muda em um diagnóstico técnico

Quando avaliamos uma base existente, a medição automatizada entra como um dos insumos, não como o veredito. Ela é boa para achar o que é objetivamente detectável — violação de segurança, dependência sem suporte, duplicação. É fraca para dizer onde a equipe perde tempo.

Por isso o diagnóstico combina três leituras: o que a ferramenta detecta no código, o que o histórico de alterações mostra sobre onde o trabalho acontece, e o que quem mantém o sistema relata sobre onde a mudança dói. As três raramente apontam para o mesmo lugar, e é justamente a divergência entre elas que costuma indicar o que precisa ser tratado primeiro.