O que é dívida técnica e por que ela cresce mais rápido quando o time muda?

Dívida técnica é o custo futuro de escolher hoje a solução rápida em vez da mais limpa: cada atalho fica pendente como um empréstimo, com juros cobrados em bugs, em funcionalidades cada vez mais caras de construir e em código que ninguém quer tocar. Não é sinônimo de código ruim —é uma decisão, consciente ou não, de adiar um trabalho para depois. O problema real não é que ela exista: é não saber quanta já se acumulou, nem quem vai ter que pagar por ela.

Todo projeto de software gera alguma dívida técnica —não dá para evitar, e nem sempre é um erro. O que decide se ela vira um problema é se alguém a registra e a paga de propósito, ou se ela se acumula em silêncio até o sistema ficar mais caro de mudar do que de jogar fora e refazer.

De onde vem o termo e o que significa realmente “pagar” a dívida?

A metáfora foi criada pelo programador Ward Cunningham em 1992, num relatório sobre a construção de um sistema financeiro: ele comparou escrever código da forma mais rápida possível a pegar um empréstimo. Esse empréstimo deixa você avançar mais rápido no curto prazo, mas cada ciclo que passa sem refatorar esse código soma juros —o sistema fica mais rígido, mais lento de mudar e mais caro de entender para quem não o escreveu. “Pagar” a dívida significa dedicar tempo de desenvolvimento a reescrever, documentar ou simplificar esse código, em vez de seguir construindo funcionalidade nova em cima dele.

Quanto tempo e orçamento realmente vão embora pagando essa dívida?

O dado mais citado da indústria vem da Stripe: numa pesquisa com mais de 1.000 desenvolvedores e 1.000 executivos de nível C em cinco países, os times de engenharia relataram dedicar em média 17,3 horas semanais —42% da semana de trabalho pesquisada— a manutenção e código mal escrito, em vez de construir funcionalidade nova (Stripe, The Developer Coefficient, 2018). 79% dos executivos consultados disseram que o tempo perdido com sistemas legados era uma preocupação significativa para o negócio.

A McKinsey entrevistou 50 CIOs de grandes empresas de serviços financeiros e tecnologia e descobriu que, em média, a dívida técnica representa entre 20% e 40% do valor de todo o patrimônio tecnológico de uma empresa —e que entre 10% e 20% do orçamento reservado para produto novo acaba destinado a resolver problemas herdados (McKinsey, Tech debt: Reclaiming tech equity, 2020). O Global Technology Leadership Study mais recente da Deloitte coloca esse arrasto numa faixa parecida: entre 21% e 40% do gasto total em tecnologia de uma organização (Deloitte, Global Technology Leadership Study, 2026).

Por que ela se acumula mais rápido quando o time que escreveu o código muda?

O código não documenta as razões por trás de cada decisão —isso vive na memória de quem escreveu. Quando esse time muda no meio do projeto, essa razão se perde junto: o próximo time herda o resultado sem o contexto, e na dúvida, quase ninguém refatora código alheio que não entende por completo —prefere construir código novo ao redor, até que mexer naquela parte do sistema passe a dar medo. É exatamente isso que acelera o acúmulo: não é que um time novo escreva pior, é que cada passagem de bastão reseta o conhecimento tácito que mantinha a dívida sob controle.

É a mesma razão pela qual um squad que já trabalhou junto em outros projetos —e continua sendo o mesmo time do início ao fim— acumula menos dívida invisível do que um montado do zero a cada contrato: não porque as pessoas sejam melhores, mas porque o conhecimento sobre por que o sistema foi construído de uma forma específica não se perde pelo caminho.

Toda dívida técnica é ruim?

Não. O próprio Martin Fowler, em 2009, propôs pensar nela em dois eixos: se foi uma decisão deliberada ou inadvertida, e se foi uma decisão prudente ou imprudente (Martin Fowler, Technical Debt Quadrant, 2009). Tomar um atalho consciente para validar uma hipótese de negócio rápido —sabendo que vai ser preciso voltar naquela parte do código depois— é dívida prudente e deliberada. O problema não é tomar esse atalho: é não anotar isso em lugar nenhum e descobrir meses depois, quando já ninguém lembra que era temporário.

Como evitar que ela se acumule sem travar a velocidade de entrega?

A forma mais eficaz de não acumular dívida invisível não é parar e refatorar tudo antes de seguir em frente —é fazer com que cada entrega fique documentada com critérios explícitos desde o momento em que é definida, e que o trabalho passe por revisão antes de entrar no resto do sistema. Na Zenit, cada milestone é combinado com critérios de aceitação assinados de antemão, então “concluído” não é uma palavra ambígua que cada um interpreta de um jeito seis meses depois.

O Kaizen soma outra camada durante a execução: não monta só o match inicial, ele acompanha o projeto milestone a milestone e volta à empresa se detectar um sinal real de risco —antes que vire o tipo de atalho silencioso que ninguém documentou.

A visibilidade também importa: se a evidência de avanço é o próprio código —commits, pull requests, code review— em vez de um relato verbal, a dívida que está se acumulando fica visível para a empresa, em vez de esconder atrás de um “está tudo indo bem” na reunião semanal.

Dívida técnica não se elimina —nenhum projeto de software chega a zero. O que muda o resultado é se alguém sabe quanta existe, quem a gerou e quando planeja pagá-la, em vez de descobrir só quando o sistema já ficou caro demais para mexer.