Engenharia de Software 3 min min de leitura 4 views

Dívida técnica não é sobre código feio — é sobre decisões que ninguém revisita

E
Eduardo Piasson
03 Aug 2026
Dívida técnica não é sobre código feio — é sobre decisões que ninguém revisita

O mito do código feio

Quando alguém abre um arquivo antigo e torce o nariz, é comum ouvir "isso aqui é dívida técnica". Quase sempre não é. Código feio que funciona, que ninguém precisa mexer e que não trava nada é só código feio — inofensivo, ainda que incômodo aos olhos.

Dívida técnica de verdade é outra coisa: é uma decisão tomada conscientemente (ou não) sob uma restrição de tempo, conhecimento ou escopo, que acumula juros enquanto o sistema cresce em cima dela. A analogia com dívida financeira é literal — você pegou um atalho para entregar mais rápido, e esse atalho cobra parcelas até ser quitado.

De onde vem a dívida de verdade

Na prática, a dívida técnica nasce de três lugares:

  • Deliberada e informada. O time sabia que existia um jeito melhor, mediu o prazo e escolheu o atalho conscientemente — geralmente para validar algo antes de investir na versão certa.
  • Acidental. Ninguém percebeu o problema na hora. Só ficou visível quando o sistema cresceu e a decisão original deixou de fazer sentido.
  • Herdada. O time atual nem estava lá quando a decisão foi tomada. Recebeu o juro sem ter assinado o contrato.

O erro comum é tratar as três do mesmo jeito. Dívida deliberada tem dono e prazo — ela deveria estar documentada, com uma data para ser revisitada. Dívida acidental e herdada exigem investigação antes de qualquer correção, porque ninguém sabe ao certo por que aquilo está do jeito que está.

Como pagar sem parar o produto

Ninguém convence a diretoria a parar seis semanas para "refatorar tudo" — e nem deveria, porque isso raramente é o problema real. O que funciona é tratar dívida como qualquer outro item de prioridade, com um critério simples:

  1. Ela está no caminho de alguma entrega futura? Se sim, pagar agora é mais barato do que pagar depois de construir mais coisa em cima.
  2. Ela está causando incidente recorrente? Bug que volta é sinal de que a dívida já está cobrando juro composto.
  3. Alguém entende por que aquilo existe? Se a resposta é não, o primeiro passo não é reescrever — é investigar antes de destruir contexto que pode ser importante.

Dívida que não atende a nenhum desses três critérios pode esperar. E está tudo bem — nem toda dívida precisa ser quitada, algumas nunca vão cobrar juro suficiente para justificar o esforço.

O hábito que evita a bola de neve

O que separa times que vivem apagando incêndio de times que evoluem com previsibilidade não é talento, é um hábito simples: registrar a dívida no momento em que ela é criada, com uma frase de por quê. Um comentário, um item no board, uma linha num documento — não importa o formato, importa que a decisão fique visível para quem vier depois.

Dívida técnica não é vergonha de engenharia. É parte do trabalho de construir algo rápido o suficiente para existir no mundo real. O problema nunca foi contraí-la — foi esquecer que ela existe.

Compartilhar

Newsletter

Novos artigos direto no seu email.

✓ Verifique seu email para confirmar a inscrição.

Posts relacionados