Um sistema pode funcionar sem falhas hoje e, mesmo assim, custar caro amanhã. Essa lógica está no centro da dívida técnica, um dos conceitos mais citados e menos compreendidos no desenvolvimento de software. Jean Pierre Lessa e Santos Ferreira, CTO com atuação em arquitetura de sistemas e engenharia de software, observa que o problema raramente aparece como falha visível: manifesta-se como lentidão, quando cada funcionalidade nova demora mais para sair.
A metáfora da dívida financeira funciona porque descreve um mecanismo real. Toda decisão de atalho no código gera um custo futuro, os chamados juros, que crescem enquanto a base não é revisada. Diferente de uma dívida bancária, esse custo não aparece em relatório financeiro algum: se esconde em prazos que estouram e em times que gastam mais tempo lidando com o sistema antigo do que construindo o próximo.
Os quatro tipos de decisão que geram dívida técnica
O termo foi cunhado pelo programador Ward Cunningham e depois organizado por Martin Fowler em quatro categorias. Existe a dívida deliberada e prudente, quando a equipe escolhe uma solução mais simples para cumprir um prazo e já sabe que vai revisá-la depois. Existe também a deliberada e imprudente, quando o atalho é tomado sem plano de correção.
Do outro lado estão as dívidas inadvertidas. Jean Pierre Lessa e Santos Ferreira alerta para o fato de que a decisão prudente surge quando a equipe só percebe o problema depois, ao aprender uma forma melhor de resolver algo que já parecia pronto. A imprudente, por sua vez, nasce de falta de experiência ou de pressa. Reconhecer o quadrante muda a forma de tratar cada dívida.
Por que ela cresce mesmo em equipes disciplinadas?
Jean Pierre Lessa e Santos Ferreira aponta que a dívida técnica não é sinônimo de descuido. Prazos curtos, ausência de testes automatizados e sistemas legados que seguem funcionando por anos são comuns em qualquer operação, inclusive nas mais organizadas. O problema surge quando esses fatores se acumulam sem que ninguém meça o tamanho do que ficou para trás.
Sistemas legados costumam ser o ponto mais delicado. Seguem em produção, atendendo usuários, mas cada funcionalidade nova exige mais cuidado que a anterior. A arquitetura que fazia sentido no início do projeto nem sempre acompanha o crescimento do negócio, e cada ajuste sobre a estrutura original eleva o risco da mudança seguinte.
Como medir o que fica invisível no dia a dia?
Diferente de uma dívida financeira, a técnica não aparece em nenhum extrato. Por isso, equipes recorrem a métricas: complexidade do código, duplicação de trechos, cobertura de testes automatizados e índices de manutenibilidade. Ferramentas de análise estática transformam esses números em um retrato objetivo da base de código.
Medir sozinho não resolve nada, mas cria a base para priorizar. Jean Pierre Lessa e Santos Ferreira ressalta que, sem esses números, refatorar um módulo vira debate de opinião entre quem quer avançar rápido e quem já sofreu com o sistema antigo. Com dados reais, discute-se onde o risco é maior, não quem tem razão.
Quando pagar a dívida e quando deixá-la em aberto?
Nem toda dívida técnica precisa ser resolvida de imediato. Um trecho frágil, mas isolado, pode esperar, mas uma dívida no caminho de todas as novas funcionalidades tende a custar mais quanto mais tempo permanece intacta. Para Jean Pierre Lessa e Santos Ferreira, esse tipo de decisão deveria envolver também áreas de governança e gestão de projetos, não apenas o time técnico.
Um critério prático é perguntar quanto a dívida atrasa a entrega seguinte. Se o custo reaparece toda vez que alguém mexe naquele trecho, a prioridade sobe. Se o impacto fica restrito e raro, o time pode conviver com ela por mais tempo, desde que a escolha seja registrada.
O que muda quando a dívida técnica vira pauta de negócio?
Tratar dívida técnica como problema exclusivo de programadores é um erro recorrente. Ela influencia prazo, custo e capacidade de crescer, o que a torna também questão de liderança em tecnologia. Decisões tomadas hoje, numa linha de código, aparecem meses depois na velocidade com que a empresa lança algo novo.
Nessa lógica, Jean Pierre Lessa e Santos Ferreira frisa que times maduros não evitam a dívida técnica: eles a administram. Aceitam algum grau dela como parte do ritmo de qualquer projeto, mas mantêm visibilidade sobre onde ela está e o que custaria resolvê-la. É essa visibilidade que separa sistemas que escalam de sistemas que travam.