Definição curta

Fraqueza de concepção ou de arquitetura de um software que a empresa decidiu que será tratada, e que por isso carrega um custo de pagamento e um lugar entre as prioridades. Enquanto essa decisão não é tomada, a fraqueza continua sendo um desconforto ou um risco latente.

Definição detalhada

No uso corrente, a palavra cobre tudo o que um desenvolvedor lamenta num código existente: um atalho antigo, uma arquitetura frágil, uma complexidade acumulada, uma biblioteca obsoleta. A analogia financeira ali é puramente descritiva — fala-se em dívida para dizer que algo vai custar mais tarde, sem que nenhum credor, nenhum prazo e nenhum valor sejam nomeados.

Nos artigos deste blog, a palavra é reservada ao que já passou por uma decisão. Uma fraqueza conhecida há anos, que ninguém colocou no programa, não é uma dívida: ela não tem data, nem custo decidido, nem responsável pelo pagamento. Ela vira dívida quando a empresa julga que o custo de conviver com ela supera o custo de tratá-la — porque ela trava uma estratégia, atrasa fortemente o time, expõe a um risco, degrada a qualidade percebida pelo cliente, ou impede uma mudança importante no produto.

O uso de campo diverge claramente do sentido adotado aqui: no campo, "temos dívida" designa um estado permanente do sistema, e não dispara nada. O sentido adotado aqui faz da palavra um status que se conquista, não uma constatação que se repete.

Uso no domínio

Revisão de priorização entre um assunto de produto e um assunto técnico, argumentação de um desenvolvedor diante de um comitê, decisão de entrada de um assunto técnico no roadmap, definição de uma estratégia de tratamento distinta da gestão diária de bugs.

Sinônimos e variantes

"A dívida" na forma abreviada · "dívida de arquitetura" quando a fraqueza é estrutural · "desconforto técnico" e "risco latente" para o estado anterior à decisão.

Não confundir com

• Defeito — diferença entre o comportamento esperado de um software e seu comportamento real; a dívida não tem comportamento defeituoso visível, ela custa na evolução.
• Política zero bug — regime que proíbe manter um defeito conhecido sem decisão; ele recai sobre desvios de comportamento, nunca sobre fraquezas de concepção.
• Roadmap — visão dos grandes assuntos assumidos, preparados e possíveis; a dívida técnica só aparece ali depois da decisão de tratá-la.
• Dívida de compreensão — diferença entre o que um time produziu e o que ele sabe sobre o que produziu; ela se paga em incapacidade de decidir o que refazer, enquanto a dívida técnica se paga em trabalho de refatoração.
• Refatoração — gesto de melhorar o código por dentro sem mudar o comportamento; é um meio de pagamento, não a dívida em si.
• Complexidade essencial — dificuldade inerente ao problema tratado, que nenhum trabalho de arquitetura elimina.
• Reconstrutibilidade — propriedade de um sistema que um time saberia refazer em outro lugar a partir dos seus contratos, das suas regras de negócio e dos seus testes; ela qualifica o que se sabe dizer do sistema, não a qualidade da sua concepção.
• Dívida de compreensão — diferença entre o que um sistema faz e o que o time responsável sabe explicar; ela recai sobre a cabeça de quem mantém, enquanto a dívida técnica recai sobre o estado do código, e ela não espera decisão nenhuma para existir.

Exemplos

Uma arquitetura frágil, conhecida há muito tempo, que não impede ninguém de entregar: desconforto, não dívida.

A mesma arquitetura, no dia em que ela trava uma frente estratégica e a empresa decide refazê-la: dívida, com um lugar a encontrar entre as prioridades.

Ambiguidades / debates

A analogia financeira é contestada: a dívida supõe um empréstimo voluntário, enquanto boa parte do que a palavra cobre foi acumulada sem escolha, por desconhecimento ou por pressão de prazo. Alguns propõem reservar o uso aos atalhos deliberados.

Uma segunda oscilação, mais operacional: contar a dívida técnica dentro da capacidade do time ou dentro dos assuntos do roadmap. As duas respostas circulam, e não envolvem o mesmo decisor.