Dívida técnica como carteira de crédito: falta a coluna da taxa de juros

Em um estudo publicado no Journal of Systems and Software em 2019, 43 desenvolvedores relataram, duas vezes por semana durante sete semanas, quanto do tempo de trabalho a dívida técnica lhes havia custado. A média foi de 23,1%. A mediana ficou em 17,1% e o desvio padrão em 21,1%, quase do tamanho da média, e seis desenvolvedores disseram ter perdido mais da metade do tempo. Agrupada por empregador, a cifra ia de 18,1% numa empresa a 51,5% em outra. Terese Besker, Antonio Martini e Jan Bosch, que conduziram o estudo, coletavam autorrelatos. Os números mostram que o custo é grande em algum lugar, e a distância entre empregadores mostra que a resposta muda com a base de código, de modo que nenhuma média do setor substitui a medição da sua própria.

Acho que a metáfora da dívida deveria ser levada mais ao pé da letra do que a maioria das equipes a leva. Times de engenharia falam em dívida, juros e amortização, e poucos mantêm a contabilidade que esse vocabulário implica. Minha tese é que cada item de dívida técnica pertence a um registro com três grandezas: um principal (as horas para quitá-lo), um juro mensal (o trabalho extra que ele acrescenta a cada mês) e uma vida útil esperada (quanto tempo o código vai existir). Juros divididos pelo principal dão uma taxa. A quitação passa então a ser uma decisão de alocação de capital, ordenada contra outros usos das mesmas horas pelo prazo de retorno. Endividar-se de propósito para aprender continua racional sob esse ponto de vista. O alvo é o juro que ninguém mede, porque, sem um número, toda discussão sobre quitação acaba favorecendo quem fala mais alto.

O escopo aqui é a gestão de engenharia. Sculley e colegas descreveram a variante de aprendizado de máquina em 2015, tema de outro ensaio deste site, e o registro vale para ela também. A seguir, parto do que Cunningham quis dizer, acrescento Fowler e McConnell, desenvolvo um exemplo com números inventados, confiro o que as medições publicadas sustentam e então enfrento a melhor objeção.

Cunningham se endividou para aprender, e disse isso duas vezes

A metáfora vem de um relato de experiência curto que Ward Cunningham escreveu para a OOPSLA em 1992 sobre o WyCash, um sistema de gestão de carteiras de títulos de caixa. Ele comparou o lançamento de código na primeira versão a contrair uma dívida. Um pouco de dívida, escreveu, acelera o desenvolvimento desde que seja paga logo com uma reescrita, e cada minuto gasto em código que não está bem certo conta como juro. O perigo que ele apontou era o não pagamento: código demais sem consolidar torna o programa impossível de dominar, empurra os programadores para uma especialização extrema e deixa um produto inflexível. A mesma passagem faz uma observação menos citada. Ele descreveu o método em cascata como pagamento adiantado e integral, e preferia o crescimento incremental, que chamou de viável e desejável, embora nem sempre confortável. Lido assim, o relato de 1992 trata de financiamento: pergunta quando uma equipe deve pagar pelo entendimento, antes do código ou depois.

Em 2009 ele gravou um vídeo curto para corrigir a leitura que se fazia da ideia, e transcrições circulam na internet. Disse que cunhou a metáfora para explicar ao chefe por que a equipe estava refatorando o programa de modo a refletir o que havia aprendido sobre os objetos financeiros. Não fazer isso significava tropeçar repetidamente no descompasso, o que atrasava o time do mesmo jeito que os juros atrasam um devedor. Para ele, tomar emprestado era boa ideia, e lançar software às pressas para ganhar experiência também, desde que o aprendizado fosse depois devolvido ao código. Se isso nunca acontece, os juros acabam consumindo tudo, e ele descreveu um programa que só ganha funcionalidades até não conter mais entendimento algum e cada mudança demorar mais.

Em seguida ele tratou do mal-entendido de frente. Blogueiros, disse, entenderam a metáfora como escrever código ruim de propósito e consertar depois. Ele nunca defendeu escrever código mal. Defendia código que reflete o seu entendimento atual, mesmo parcial, e acrescentou que a dívida só trabalha a seu favor se o código estiver limpo o bastante para ser refatorado quando você aprender mais. Quem toma emprestado precisa, portanto, deixar para trás um código cuja intenção um leitor consiga acompanhar, porque a quitação é uma refatoração e a refatoração exige um ponto de partida claro.

O quadrante de Martin Fowler, publicado em outubro de 2009, classifica a dívida em dois eixos: deliberada ou inadvertida, prudente ou imprudente. Ele colocou a dívida que Cunningham descreveu no canto prudente e inadvertido, a que aparece porque até boas equipes só enxergam o desenho melhor depois de construir o sistema. A dívida prudente e deliberada, uma troca consciente de custo futuro por lançamento mais cedo, também está no esquema. Uma bagunça é dívida imprudente nos termos dele, e produz juros paralisantes. A distinção define o que merece entrar num registro. Um empréstimo tomado para aprender tem finalidade, caminho de quitação e preço. Uma bagunça não tem nada disso, e chamá-la de dívida veste um acidente de decisão. Eu trataria a bagunça como problema de qualidade e reservaria o registro para itens que alguém seria capaz de defender como escolha.

O juro corre com o uso, então um módulo intocado não custa nada

O texto de Fowler sobre dívida técnica, de 2003 e reescrito em 2019, dá a definição de trabalho mais clara. Juro, para ele, é o esforço extra que cada nova funcionalidade exige por causa da má qualidade interna, e limpar é amortizar o principal. Vem em seguida o ponto que mais importa para a alocação. O juro só é pago quando se modifica o código afetado, de modo que a sujeira num canto estável do sistema pode ser deixada em paz, e a atenção deve ir para onde a atividade é alta. Ele também marca onde a metáfora se quebra: o juro de verdade se acumula com o tempo, e este se acumula com o uso.

Daí sai uma fórmula. O juro mensal é o número de mudanças por mês multiplicado pelas horas extras que cada mudança consome. Um módulo horrível em que ninguém mexe não paga juro nenhum, enquanto um módulo apenas desajeitado que todas as equipes tocam todo dia pode ser o item mais caro dos livros. O principal entra na decisão como o preço de eliminar esse fluxo. Juro mensal sobre principal é a taxa mensal, e principal sobre juro mensal é o prazo de retorno em meses.

O white paper de Steve McConnell para a Construx, de 2008, acrescenta três pontos práticos. O custo de um atalho é o caminho rápido, mais o caminho bom depois, mais o custo de arrancar o caminho rápido, de modo que o preço real do empréstimo é maior que a economia visível do atalho. Parte do que as equipes chamam de juro é multa por atraso, um custo único de substituir o código, enquanto o juro propriamente dito é a lentidão contínua do trabalho relacionado. E muitas vezes existe uma terceira opção, um caminho rápido isolado de modo a não atrasar mais nada, que carrega uma taxa de juros perto de zero. McConnell também pediu que as equipes mantenham uma lista de dívidas com esforço estimado para cada item, tratem como crítico qualquer item sem solução após 90 dias e recusem atalhos pequenos demais para entrar no registro. Para a quitação, sugeriu gastar a primeira iteração depois de um lançamento com a dívida de curto prazo. As regras dele dependem do tempo decorrido. A regra de retorno que apresento adiante depende do que o juro custa.

Endividar-se de propósito pode sair mais barato

Tome um exemplo inventado. Uma equipe pode construir uma funcionalidade do jeito bom em 160 horas, ou do jeito rápido em 60. Se a funcionalidade sobrevive, a versão rápida será substituída pela boa ao custo de 160 horas mais 20 para arrancar o código antigo. Enquanto vive, a versão rápida acrescenta 2 horas extras a cada mudança, e três mudanças por mês dão 6 horas de juros. Suponha que ela sobreviva e seja substituída depois de seis meses. O total é 60 + 180 + 36 = 276 horas, que são 116 a mais que as 160 do caminho bom. Suponha, ao contrário, que a funcionalidade seja descartada depois de três meses porque os usuários não a quiseram. O total é 60 + 18 = 78 horas, uma economia de 82.

O empréstimo é, portanto, uma aposta sobre a sobrevivência da funcionalidade. Ele empata quando a probabilidade de abandono é 116 / (116 + 82), cerca de 59%. Se a equipe estima em 30% a chance de descartar a funcionalidade, o custo extra esperado de se endividar é 0,7 × 116 − 0,3 × 82 = 56,6 horas. Suponha agora que a versão rápida chegue três semanas antes, número que o exemplo não deriva e que depende da equipe. Endividar-se compensa quando cada semana de feedback antecipado dos usuários vale mais que cerca de 19 horas de engenheiro. Para um produto cuja principal incerteza é se alguém quer a funcionalidade, a régua é baixa. Para uma funcionalidade que certamente fica, é alta, já que o ganho de lançar cedo vem da chance de nunca ter de pagar o custo da quitação.

A condição de Cunningham aparece na aritmética. Supus que arrancar o código rápido custa 20 horas, o que vale se o código for limpo e refletir o que a equipe entendia. Se o caminho rápido for um emaranhado que precisa ser reescrito, ponha o custo de remoção em 160 horas. O caso de sobrevivência passa a custar 416 horas, 256 a mais que o caminho bom, e a probabilidade de abandono no ponto de equilíbrio sobe para 76%. O mesmo atalho é uma aposta sensata num nível de ofício e uma aposta ruim em outro, que é o sentido prático da insistência dele em código limpo o bastante para ser refatorado.

A Design Stamina Hypothesis de Fowler, de 2007, afeta o horizonte. Ele propôs que o ponto em que um bom desenho passa a superar a ausência de desenho em funcionalidade entregue acumulada chega em semanas, não em meses, e nas palavras dele é uma conjectura, já que produtividade e qualidade de desenho são difíceis de medir. Se for verdade, os empréstimos devem ser pequenos e curtos. Se o ponto de cruzamento estiver mais perto de meses para o seu time, o exemplo acima deve ser refeito com períodos de juros mais longos, e o equilíbrio se desloca. Não sei dizer qual dos dois vale para a sua base de código, e o texto de Fowler também não diz.

Um registro precisa de cinco campos por item

Eu manteria o registro em uma página, com estes campos para cada item:

1. Principal: as horas para quitar o item por inteiro, estimadas pelas pessoas que fariam o trabalho, em faixa se elas discordarem.
2. Mudanças por mês: com que frequência o código afetado foi modificado nos últimos dois trimestres, tirada do controle de versão.
3. Horas extras por mudança: o tempo adicional em comparação com uma mudança equivalente em outra parte do sistema.
4. Vida útil esperada em meses: quanto falta para o código ser aposentado ou substituído por outros motivos.
5. Motivo e responsável: o que se aprendeu ou se comprou ao tomar o empréstimo, e quem decide sobre a quitação.

Com isso, o juro mensal é mudanças vezes horas extras, e o retorno é o principal dividido pelo juro. A regra que proponho tem três faixas, com limites que você deve fixar a partir das suas alternativas. Um item com retorno abaixo de seis meses e abaixo da sua vida útil é quitado sem mais debate. Um com retorno entre seis e doze meses disputa o orçamento de quitação do trimestre, ordenado pelo retorno. Qualquer coisa acima de doze meses, ou com retorno maior que a vida útil, espera e continua nos livros. O teto de doze meses deveria ser igual ao retorno que você exige de uma funcionalidade ou de um projeto de infraestrutura, porque a quitação disputa com eles as mesmas horas.

Segue um registro ilustrativo, também inventado, com orçamento de quitação de 200 horas no trimestre.

Item	Principal (h)	Juro (h/mês)	Taxa mensal	Retorno (meses)	Vida útil (meses)	Decisão
Checkout sem testes de integração	80	15	18,8%	5,3	36	Quitar já
Retentativas de cobrança feitas à mão	120	15	12,5%	8,0	36	Quitar, cabe no orçamento
Papéis fixos no código da ferramenta de admin	60	6	10,0%	10,0	24	Espera, orçamento esgotado
Fronteiras do módulo de pedidos	600	48	8,0%	12,5	36	Espera, rever depois
Gerador de relatórios legado	200	4	2,0%	50,0	12	Deixar quieto

O módulo de pedidos tem de longe a maior conta de juros, 48 horas por mês contra 15 do item seguinte, e ainda assim não é o primeiro da fila. Quitá-lo custa 7,5 vezes mais que os testes do checkout, enquanto seu juro é só 3,2 vezes maior. Ao longo dos seus 36 meses de vida, ele economizaria 1.128 horas, já descontado o principal, mais que qualquer outro item, e por isso ignorá-lo seria um erro. O problema é de racionamento de capital, como em qualquer orçamento: com 200 horas disponíveis, os testes do checkout e as retentativas de cobrança devolvem 880 horas líquidas entre os dois, e o módulo de pedidos simplesmente não cabe naquele trimestre. Uma quitação em etapas é a resposta sensata: uma primeira fatia que elimine parte do juro por uma fração do principal. O gerador de relatórios legado tem retorno de 50 meses num código que terá sumido em 12. A linha dele no registro documenta a decisão de não fazer nada, e esse registro vale a pena ter.

As estimativas vão errar, então testei o tamanho do erro que a regra aguenta. Multipliquei cada valor de juro por um fator aleatório entre meio e dois, rodei 10.000 sorteios e apliquei a mesma regra. O gerador de relatórios e o módulo de pedidos nunca foram financiados. A frequência de financiamento foi de cerca de 91% para os testes do checkout, 67% para as retentativas de cobrança e 39% para os papéis da ferramenta de admin, e a economia líquida média ficou em aproximadamente 735 horas, contra 880 com números perfeitos, cerca de 83%. Financiar os itens em ordem aleatória dentro do mesmo orçamento rendeu em média cerca de 440 horas. Erros de um fator de dois custaram cerca de um sexto do valor, e ignorar os números custou cerca de metade. Como os dados de entrada são inventados, a simulação mostra apenas que uma regra desse formato tolera ruído desse tamanho.

Meça o juro nos seus próprios tickets, porque pesquisas enganam

As cifras publicadas mostram como são frouxas as estimativas disponíveis. O artigo de Besker e colegas, de 2019, traz uma média de 23,1% no seu painel de 43 desenvolvedores e, numa replicação com 177 itens de trabalho relatados por 47 desenvolvedores de uma só empresa, média de 28,5% e mediana de 20%. Um estudo anterior citado pelo artigo, com 258 respondentes de questionário mais 32 entrevistas, chegou a uma estimativa de 36%. Testar foi a atividade extra mais comum no painel. Em 24% das ocasiões de relato, os desenvolvedores disseram que a dívida existente os havia obrigado, ao menos em grau mínimo, a criar dívida nova, e em 3% das ocasiões em grau elevado. Esse último resultado importa para o registro, porque o juro não fica parado: gambiarras geram novas gambiarras. Se as 15 horas mensais dos testes do checkout crescessem 3% ao mês, taxa inventada, o custo em 36 meses seria de 949 horas em vez de 540. Um item adiado pode custar mais do que dizia a primeira estimativa, e esse é um motivo para reprecificar o registro todo trimestre.

O relatório The Developer Coefficient, da Stripe, de 2018, produzido com a Harris Poll a partir de uma pesquisa com mais de 1.000 desenvolvedores e mais de 1.000 executivos de nível C, informa uma semana de trabalho de 41,1 horas para o desenvolvedor. Dessas, os respondentes estimaram 17,3 horas por semana desperdiçadas com manutenção, que o gráfico do relatório divide em 13,5 horas de dívida técnica e 3,8 horas de código ruim. São estimativas dos respondentes, e o relatório vem de uma empresa de pagamentos que apresenta seus achados como argumento para aproveitar melhor os desenvolvedores. As 17,3 horas são 42% da semana, e um artigo de 2022 de Adam Tornhill e Markus Borg cita a Stripe para a afirmação de que a dívida técnica pode desperdiçar até 42% do tempo dos desenvolvedores. No gráfico da própria Stripe, a fatia da dívida técnica é de 13,5 horas, ou 33%. Os 42% englobam tudo que foi rotulado como manutenção, inclusive depurar e modificar código, e por isso a cifra de manchete está acima do que a fonte sustenta para a dívida isolada.

O estudo do próprio Tornhill e Borg é mais útil porque mediu. Eles analisaram 39 bases de código proprietárias, 30.737 arquivos no total, cruzando um índice de qualidade de código chamado Code Health com dados de tarefas do Jira ao longo de 6 a 12 meses. Comparando médias, os arquivos da pior categoria tinham 15 vezes mais defeitos registrados que os arquivos saudáveis, levavam 124% mais tempo para serem desenvolvidos e apresentavam tempos máximos de ciclo nove vezes maiores. O mesmo artigo acrescenta uma cifra que toma de uma pesquisa de Martini, Besker e Bosch, que não abri: afirma que apenas 7,2% das organizações acompanham a dívida técnica de modo metódico. O resumo dessa pesquisa no repositório da Chalmers dá 7,2% como a parcela de seus 226 respondentes, e por isso leio o número como parcela de pessoas, não de empresas. Tornhill e Borg apontam eles mesmos uma ressalva: a causalidade poderia correr no sentido inverso, com o código cheio de defeitos recebendo nota ruim. Outra é visível na folha de rosto do artigo: as bases de código vieram de usuários do CodeScene, a ferramenta que calculou o índice, e a afiliação de Tornhill é a CodeScene. Mais um número importa para a alocação: apenas 350 dos arquivos, 1,14%, estavam na pior categoria, e 9,87% estavam na intermediária. Leio isso como respaldo à ideia de que a dívida cara é concentrada, e é isso que torna plausível um registro curto. O estudo não testa essa leitura.

A pesquisa de 2015 da equipe de Ernst, com 1.831 participantes, na maioria engenheiros e arquitetos de três grandes organizações, concluiu que as decisões de arquitetura eram a fonte mais importante de dívida e que os respondentes não achavam úteis as ferramentas existentes para geri-la. Eu esperaria que itens arquiteturais, como o módulo de pedidos, carregassem as maiores contas e o menor apoio de ferramentas. A coluna de juros do registro tem de vir de tickets e do controle de versão: pegue as mudanças dos últimos dois trimestres que tocaram o item, compare o tempo delas em desenvolvimento com o de mudanças equivalentes em outros lugares e multiplique a diferença pela contagem. Fazer isso à mão para cinco módulos deve levar algumas horas, o que é palpite meu e não um número medido.

Um preprint de 2026 no arXiv, de Yue Liu e colegas, revisado em outubro, examina os assistentes de IA pela mesma lente. Ele acompanhou cerca de 300.000 commits escritos por IA em aproximadamente 6.300 repositórios públicos com análise estática e encontrou 484.366 problemas, 89,3% deles code smells, com 22,7% ainda presentes na última revisão. Essas contagens descrevem um inventário, e pela lógica de Fowler inventário não é juro, já que um smell num arquivo que ninguém altera não custa nada. Minha inferência, que o estudo não testa, é que gerar código reduz o preço de se endividar, e empréstimo mais barato é tomado com mais frequência. Se isso se confirmar, uma equipe ganha ao conhecer sua taxa antes que o volume assistido por IA chegue, já que depois haverá mais código para precificar.

A objeção mais forte: o juro é incerto demais para ordenar qualquer coisa

O melhor argumento contra tudo isso é que um registro fabrica precisão. A evidência acima sustenta parte dele. Os autorrelatos diferem por quase um fator de três entre empregadores, as estimativas das pesquisas são autodeclaradas e não foram conferidas contra os tickets de nenhuma base de código, e o próprio Fowler admite que qualidade de desenho e produtividade são difíceis de medir. Uma coluna de juros preenchida com decimais confiantes pode fazer um palpite parecer auditoria, e equipes que disputam orçamento de quitação têm motivo para inflar os números. Um gerente que confia mais na tabela do que nas pessoas mais próximas do código tomou uma decisão pior que a de quem simplesmente perguntou a elas.

Aceito o risco, e vejo três razões para o registro ainda valer a manutenção. A primeira: a carteira inventada acima tem retornos que variam por um fator de nove, de 5,3 meses a 50, e uma regra baseada no retorno sobreviveu a erros de um fator de dois. Uma carteira real pode ser mais apertada, caso em que o ruído pesa mais, mas meu palpite é que um fator de dois é mais ou menos a precisão que algumas horas de análise de tickets conseguem alcançar. A segunda: a alternativa a uma estimativa explícita é uma implícita, feita por quem falar primeiro na reunião de planejamento, sem registro algum para conferir depois. Um registro pode ser auditado, porque as horas extras por mudança são observáveis a posteriori, e a reprecificação de cada trimestre mostrará quais estimativas erraram. A terceira: a manipulação tem um contrapeso parcial, já que tickets, e não opiniões, devem alimentar a coluna de juros, e alguém de fora da equipe que quer o orçamento deve conferi-la.

O registro também tem limites que nenhum cuidado elimina. Ele precifica o juro em horas, e parte do juro é paga em outras moedas. O próprio aviso de Cunningham sobre especialização extrema descreve um custo que aparece como integração lenta de novas pessoas e dependência de um engenheiro que ninguém consegue substituir, e nenhum dos dois aparece no tempo de ciclo. Atalhos de segurança carregam uma perda esperada, não um fluxo constante de horas extras. Os itens também interagem, de modo que quitar um pode mudar o juro de vários outros. Uma tabela de linhas independentes não captura isso, e nenhuma das fontes acima oferece um método que capture.

A primeira versão cabe em uma página. Liste os cinco módulos que seu time mais alterou no último trimestre, levante os tempos de ciclo das mudanças que os tocaram, subtraia a mediana de mudanças equivalentes em outras partes e multiplique pela contagem. O que não consigo resolver é como pôr um número no juro que se paga em pessoas, e nenhuma das fontes que li tenta isso.

Fontes

1. Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA '92 Experience Report, datado de 26 de março de 1992. http://c2.com/doc/oopsla92.html
2. Cunningham, W. (2009). Debt Metaphor (vídeo, YouTube). Não assisti ao vídeo; o ensaio se apoia em resumos da transcrição publicados por Philip Schwarz, "The Debt Metaphor: Ward Cunningham in his 2009 YouTube video", Speaker Deck, e na citação da mesma passagem pela Agile Alliance. https://speakerdeck.com/philipschwarz/the-debt-metaphor-ward-cunningham-in-his-2009-youtube-video
3. Fowler, M. (2009). Technical Debt Quadrant. martinfowler.com, 14 de outubro de 2009. https://martinfowler.com/bliki/TechnicalDebtQuadrant.html
4. Fowler, M. (2003, reescrito em 2019). Technical Debt. martinfowler.com. https://martinfowler.com/bliki/TechnicalDebt.html
5. Fowler, M. (2007). Design Stamina Hypothesis. martinfowler.com, 20 de junho de 2007. https://martinfowler.com/bliki/DesignStaminaHypothesis.html
6. McConnell, S. (2008). Managing Technical Debt. White paper de boas práticas da Construx Software, versão 1, junho de 2008. https://www.construx.com/wp-content/uploads/2019/02/CxWhitePaper_TechnicalDebt.pdf
7. Besker, T., Martini, A., Bosch, J. (2019). Software developer productivity loss due to technical debt: a replication and extension study examining developers' development work. Journal of Systems and Software 156, 41-61. https://doi.org/10.1016/j.jss.2019.06.004
8. Tornhill, A., Borg, M. (2022). Code Red: The Business Impact of Code Quality, a quantitative study of 39 proprietary production codebases. International Conference on Technical Debt (TechDebt) 2022, 11-20, doi 10.1145/3524843.3528091. Números lidos na versão do arXiv. https://arxiv.org/abs/2203.04374
9. Stripe (2018). The Developer Coefficient: Software engineering efficiency and its $3 trillion impact on global GDP, pesquisa da Harris Poll para a Stripe, setembro de 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf
10. Ernst, N., Bellomo, S., Ozkaya, I., Nord, R., Gorton, I. (2015). Measure it? Manage it? Ignore it? Software practitioners and technical debt. Proceedings of the 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE), 50-60. https://sei.cmu.edu/library/measure-it-manage-it-ignore-it-software-practitioners-and-technical-debt
11. Liu, Y., Widyasari, R., Zhao, Y., Irsan, I. C., Chen, J., Lo, D. (2026). Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild. Preprint do arXiv 2603.28592 (enviado em março de 2026, última revisão em outubro de 2026; os números do texto seguem a versão mais recente e podem mudar). https://arxiv.org/abs/2603.28592
12. Exemplo ilustrativo de endividamento: caminho bom 160 h, caminho rápido 60 h, substituição de 160 h mais 20 h para arrancar o código (160 h na variante emaranhada), 6 h por mês de juros, sobrevivência por 6 meses ou abandono após 3 meses, probabilidade de abandono de 30%, versão rápida supostamente lançada três semanas antes. Tudo inventado; aritmética conferida com Python.
13. Registro ilustrativo, orçamento de quitação e simulação: cinco itens com os principais, contagens de mudanças, horas extras e vidas úteis mostrados na tabela, orçamento de 200 h, crescimento mensal de 3% do juro no exemplo de composição e 10.000 sorteios de um fator de erro entre 0,5 e 2 sobre cada valor de juro. A regra financia itens cujo retorno estimado é de no máximo 12 meses e menor que a vida útil, em ordem de retorno, até esgotar o orçamento. Os resultados foram estáveis em quatro sementes aleatórias, e a referência de ordem aleatória (cerca de 440 h) é a economia líquida média sobre repetidas ordenações aleatórias dos cinco itens dentro do mesmo orçamento. Tudo inventado; calculado com Python.
14. Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., Dennison, D. (2015). Hidden Technical Debt in Machine Learning Systems. Advances in Neural Information Processing Systems 28 (NeurIPS 2015). Citado apenas para atribuição; nenhum número foi tirado dele.
15. Martini, A., Besker, T., Bosch, J. (2018). Technical debt tracking: current state of practice: a survey and multiple case study in 15 large organizations. Science of Computer Programming 163, 42-61, doi 10.1016/j.scico.2018.03.007. Citado por meio de Tornhill e Borg (2022) para a cifra de 7,2%; li apenas o resumo no registro do repositório da Chalmers (https://research.chalmers.se/en/publication/541489), que dá 7,2% como a parcela de seus 226 respondentes que acompanham a dívida técnica de modo metódico, não uma parcela de organizações.