O diretor de tecnologia, Jean Pierre Lessa e Santos Ferreira, usa uma analogia direta para descrever dívida técnica: é como um financiamento com juros que crescem enquanto ninguém presta atenção. O sistema continua funcionando, as entregas continuam saindo, e o custo de manter tudo operando aumenta gradualmente até o momento em que qualquer mudança pequena exige esforço desproporcional.
O problema com a dívida técnica silenciosa é exatamente o silêncio, já que ela não gera alertas. Não aparece no dashboard de monitoramento. No entanto, aparece na velocidade das equipes, no tempo de cada deploy e na frequência de bugs que surgem em partes do sistema que ninguém deveria precisar tocar.
Como a dívida técnica se acumula sem que ninguém decida acumulá-la?
Raramente existe uma decisão consciente de criar dívida técnica. Isso porque ela surge de escolhas razoáveis feitas sob pressão de prazo, de soluções temporárias que nunca foram revisadas e de código que funcionou bem para o contexto original, mas não foi atualizado quando o contexto mudou. Com o tempo, cada camada de solução provisória cria dependências que tornam a próxima mudança mais difícil.
O custo que não aparece no orçamento
Assim como aponta Jean Pierre Lessa e Santos Ferreira, há uma distorção comum na gestão de projetos de tecnologia: o custo da dívida técnica raramente é contabilizado de forma explícita. O tempo extra que cada tarefa leva por causa de um sistema mal estruturado aparece como ineficiência da equipe, não como consequência de decisões arquiteturais do passado.
Essa invisibilidade torna a dívida técnica politicamente difícil de endereçar. É complicado justificar investimento em algo que não quebrou, mesmo quando os sinais de degradação são evidentes para quem está dentro do sistema.
Refatoração contínua ou grande reescrita: qual abordagem funciona?
A tentação de resolver dívida acumulada com uma reescrita completa é compreensível. Na prática, grandes reescritas têm uma taxa de fracasso alta. O sistema novo é construído com base em uma compreensão incompleta do que o sistema atual realmente faz, incluindo comportamentos não documentados dos quais a operação depende sem saber.
Diante disso, conforme preconiza Jean Pierre Lessa e Santos Ferreira, a estratégia de refatoração contínua, integrada ao fluxo normal de desenvolvimento, tende a produzir resultados mais sustentáveis. Sob essa abordagem, cada nova funcionalidade ou correção de bug se torna uma oportunidade de melhorar a parte do sistema que está sendo tocada.
O que muda quando a equipe trata qualidade como métrica?
Na perspectiva de Jean Pierre Lessa e Santos Ferreira, a qualidade de código precisa ser tratada como indicador de saúde do sistema, com visibilidade para a liderança técnica e critérios claros sobre o que é aceitável. Cobertura de testes, complexidade ciclomática, tempo de build e frequência de regressões contam uma história sobre a saúde técnica do produto que nenhum relatório de features consegue contar. Por isso, equipes que discutem esses números regularmente tendem a acumular menos dívida, porque tornam seu custo visível antes que ele se torne crítico.
Autor: Diego Rodríguez Velázquez
