Dívida Técnica

A dívida técnica é o custo acumulado de escolhas de implementação que foram convenientes no momento, mas que tornam as mudanças futuras mais lentas ou arriscadas. A metáfora é a de Ward Cunningham: tomar emprestado agora a capacidade futura de entregar mais cedo, com juros pagos em cada mudança subsequente até que a dívida seja quitada. Assim como a dívida financeira, ela não é inerentemente ruim, e a distinção importante reside entre a dívida contraída deliberadamente por um motivo e a dívida acumulada por negligência.

O valor da metáfora reside em tornar a questão da compensação discutida com pessoas que não programam. Enquadrar uma solicitação de refatoração como pagamento de dívida comunica algo que uma solicitação para reescrever um módulo não comunica, ou seja, que o custo já está sendo pago, em termos de entregas mais lentas e taxas de defeitos mais altas, e que a questão é se devemos continuar pagando. A formulação original de Cunningham também enfatizou que a dívida surge de uma lacuna crescente entre a estrutura do código e a compreensão atual da equipe sobre o problema, o que é uma ideia mais ampla do que simplesmente escrever código malfeito sob pressão de prazo.

Diversos aspectos distintos são agrupados sob o termo, e cada um requer uma abordagem diferente. A dívida deliberada, assumida conscientemente para cumprir um prazo real com um plano para resolvê-lo, é uma decisão legítima de engenharia. A dívida acidental, que surge devido à melhoria do entendimento da equipe após a definição do projeto, é inevitável e representa o custo normal do aprendizado. A dívida por negligência, resultante da ausência de testes, comportamentos não documentados e dependências sem manutenção, acumula-se silenciosamente e é a categoria mais custosa, pois torna cada alteração mais arriscada. Dependências desatualizadas, em particular, acarretam exposição à segurança, e não apenas inconvenientes.

Os sintomas são visíveis nas métricas de entrega antes mesmo de aparecerem no código. Estimativas crescentes para trabalhos semelhantes, uma parcela cada vez maior da capacidade gasta com defeitos, relutância em mexer em determinadas áreas e alterações em um local quebrando outros sistemas não relacionados são todos indícios de que o custo em termos de recursos se tornou substancial. As equipes frequentemente relatam esses sintomas como problemas de capacidade e solicitam mais pessoas, o que geralmente piora a situação no curto prazo.

Gerenciar essa questão exige que o trabalho seja visível no mesmo processo de planejamento que todas as outras atividades. Dívidas mantidas em uma lista separada, que só são tratadas quando há capacidade disponível, nunca são tratadas, porque nunca há capacidade disponível. Alocar uma proporção fixa de cada ciclo para elas ou vincular a remediação a trabalhos específicos nas áreas que estão sendo alteradas são as duas abordagens que resistem à pressão comercial. A alternativa, grandes renegociações periódicas, geralmente é sintoma de adiamento excessivo do trabalho e acarreta riscos muito maiores do que melhorias incrementais.

A comunicação da necessidade de remediação funciona melhor em termos de entrega do que em termos de engenharia. Afirmar que uma determinada área agora leva três vezes mais tempo para ser alterada do que áreas comparáveis, com evidências de trabalhos recentes, conecta o problema a algo que as partes interessadas não técnicas já consideram importante, enquanto descrever preocupações arquitetônicas não o faz. Quando a dívida técnica representa risco em vez de custo, como no caso de dependências não mantidas ou ausência de cobertura de testes em caminhos críticos, enquadrá-la como exposição com probabilidade e impacto é mais eficaz do que enquadrá-la como qualidade. Em ambos os casos, quantificar o custo contínuo é o que transforma uma preferência de engenharia em um argumento comercial que pode competir com o desenvolvimento de novas funcionalidades por capacidade.

Nem toda dívida deve ser paga. Códigos que funcionam, mudam raramente e não causam problemas podem permanecer como estão, independentemente da sua aparência, e o esforço despendido em sua melhoria não gera retorno. A abordagem economicamente sólida concentra a correção onde as mudanças são frequentes e onde, portanto, os juros estão sendo efetivamente pagos. Tornar essa compensação visível e reservar capacidade explícita para ela no planejamento é uma parte normal de como um desenvolvimento de produtos O engajamento é estruturado e deve ser incluído na discussão do roteiro dentro de um estúdio de produto em vez de ser tratado como uma questão de engenharia fora da discussão sobre o produto.