Acompanhei um time de sete engenheiros que recebeu a tarefa de reescrever um módulo de faturamento com três anos de patches sobrepostos. A justificativa formal era a de sempre: o código estava ilegível e qualquer mudança levava semanas. O que a reunião de kickoff não discutiu, e o que ninguém documentou, é que o módulo tinha sido escrito por um sênior que saiu em conflito com a liderança, que o substituto recebeu o código sem handover, e que duas reorganizações depois o time passou a ter medo de tocar em partes do sistema que não conhecia. Cada patch subsequente foi uma decisão individual pra contornar o medo, sem resolver o problema. A reescrita começou seis meses depois, durou nove, e produziu um módulo com estrutura similar o suficiente pra, em dois anos, estar de novo na fila de reescrita.
Esse padrão se repete com regularidade suficiente pra constituir um mecanismo, e não um acidente. Pra mim, a dívida técnica se comporta como uma sombra contábil de decisões de engenharia que o time evitou tomar, adiou por falta de mandato, ou tomou sob pressão sem condição de revisão posterior. Cada atalho, considerado isoladamente, é defensável. O agregado dos atalhos, observado ao longo de trimestres, descreve uma organização que prioriza o aparecimento de entrega sobre a sustentação do sistema, e que trata a degradação como custo invisível até o momento em que ele se torna grande demais pra ignorar. O código é o artefato legível. A dinâmica que o produz, não.
Na minha análise, a origem costuma estar em pontos de falha que operam em conjunto. Há a ausência de feedback técnico contínuo dentro do ciclo de desenvolvimento, que permite que decisões de design ruins sejam mergeadas sem contestação substantiva. Code review vira ritual de aprovação, revisores aceitam o que não entendem pra não parecer lentos, e o padrão do time se move silenciosamente pro nível do engenheiro menos experiente que escreve sem pushback. A esse problema soma-se o deslocamento sistemático da decisão de arquitetura pra fora do time, quando ela é tomada por um arquiteto distante do contexto, ou por prazos fixados sem negociação técnica, ou por um gestor que confunde velocidade com produtividade. Quando a decisão é imposta, a execução é defensiva, e código defensivo é dívida por construção. Some-se a isso o fato de que a rotatividade não é absorvida, e as camadas de adaptação que cada geração adiciona sobre o trabalho da anterior se acumulam como sedimento.
A correlação que observei entre indicadores de saúde de time e densidade de dívida é previsível. Times com alta rotatividade produzem código com mais camadas de abstração defensiva e menos testes de integração, até porque cada pessoa que passa pelo sistema resolve seu problema imediato sem condição de refatorar estruturas que não dominou. Quando as 1:1s viram performance e o engenheiro não sente espaço pra sinalizar desconforto técnico, decisões ruins vão se acumulando porque ninguém as nomeia em voz alta. E quando o gestor técnico deixa de ler código, surge uma divergência entre o que se diz em reunião e o que existe no repositório, divergência que é uma forma específica de dívida, mais difícil de medir e mais cara de reverter.
O exemplo mais ilustrativo que encontrei envolveu um serviço de integração com dezessete variáveis de ambiente não documentadas. A investigação revelou que cada variável correspondia a um incidente anterior no qual alguém tinha feito um hotfix parametrizável pra não mexer no fluxo principal. Nenhuma dessas decisões foi discutida em revisão de arquitetura, e todas foram aprovadas em code reviews com comentário do tipo "ship it". O conjunto das dezessete variáveis era o registro material de uma cultura de time que tratava incidente como evento individual, e não como sinal sistêmico, que recompensava quem resolvia rápido sem perguntar por que o problema apareceu. A dívida estava no código, mas a causa estava no ritual pós-incidente que nunca existiu.
O trade-off raramente discutido é que pagar dívida técnica sem alterar o time que a produziu tem retorno limitado. A reescrita consome ciclos, entrega um sistema temporariamente mais limpo, e a mesma dinâmica social reintroduz a mesma classe de dívida em prazo compatível com a estabilidade do time. Alterar o time, por sua vez, é caro em outra dimensão: exige conversas de feedback difíceis, revisão de como decisões técnicas são tomadas, possível reestruturação de papéis, e mandato explícito pra que engenheiros contestem prazos com base em análise técnica. Organizações que escolhem apenas a reescrita obtêm alívio de curto prazo. Organizações que tratam a dívida como sintoma obtêm uma mudança mais durável, ao custo de expor disfunções que estavam confortavelmente invisíveis.
Na minha avaliação, o que isso implica pra liderança técnica é uma inversão da pergunta padrão. Em vez de perguntar quanto tempo levaria pra limpar o módulo X, a pergunta mais produtiva é por que o módulo X ficou assim, quem estava no time nos momentos em que as decisões foram tomadas, que pressão existia naquele contexto, e o que no processo atual impediria que o próximo módulo seguisse a mesma trajetória. Nenhuma dessas perguntas é sobre código, e todas determinam o retorno de qualquer esforço de remediação técnica. Quem não consegue responder nenhuma delas está gerenciando código, sem gerenciar o sistema que produz o código, que é a unidade na qual a dívida efetivamente se forma e se dissolve.