Divida técnica: O bureau de crédito da TI
Published: 2022-10-31 15:39:14

É comum falar que qualidade do código gerado pelo time de desenvolvimento pode gerar perdas financeiras, afinal qual o impacto financeiro em deixar de corrigir um bug no software da empresa? Vou gastar mais dinheiro para corrigir esse bug?

<img width="100%" style="width:100%" src="https://media.giphy.com/media/WPtzThAErhBG5oXLeS/giphy.gif">

Conseguir mensurar todas as possibilidades é uma tarefa complexa e ouso afirmar que não existe um método para garantir com exatidão (exceto para o Doutor Estranho), precisamos sempre trabalhar com possibilidades. Porem é possível olhar para trás e perceber que algumas decisões foram ruins e provocaram algum prejuízo financeiro. O caso mais ilustre é o erro de 1 bilhão de dólares:

## O erro de 1 bilhão de dólares

[Tony Hoare](https://en.wikipedia.org/wiki/Tony_Hoare): O criador do algoritmo [_QuickSort_](https://pt.wikipedia.org/wiki/Quicksort) e também vencedor do [Prêmio Turing](https://pt.wikipedia.org/wiki/Pr%C3%AAmio_Turing) (o Prêmio Nobel de Computação) acrescentou uma funcionalidade simples na linguagem [Algol](https://pt.wikipedia.org/wiki/ALGOL) com o intuito de melhorar a performance das aplicações escritas nessa linguagem, o motivo fazia total sentido na época porque parecia prático e fácil de fazer. Várias décadas depois, ele mostrou seu arrependimento em uma conferencia:

> Eu o chamo de meu erro de um bilhão de dólares... Naquela época, eu estava projetando o primeiro sistema de tipo abrangente para referências em uma linguagem orientada a objetos. Meu objetivo era garantir que todo o uso de referências fosse absolutamente seguro, com verificação realizada automaticamente pelo compilador.
> Mas não consegui resistir à tentação de colocar uma referência nula, simplesmente porque era muito fácil de implementar. Isto levou a inúmeros erros, vulnerabilidades e falhas de sistema, que provavelmente causaram um bilhão de dólares de dor e danos nos últimos quarenta anos.
> – [Tony Hoare](https://en.wikipedia.org/wiki/Tony_Hoare), inventor of ALGOL W.

Versão original:

> I call it my billion-dollar mistake…At that time, I was designing the first comprehensive type system for references in an object-oriented language. My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler.
> But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
> – [Tony Hoare](https://en.wikipedia.org/wiki/Tony_Hoare), inventor of ALGOL W.

Pode encontrar nesse [link](https://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare/) o vídeo completo dessa conferencia.

## Impactos da divida técnica

Você acredita que uma dívida técnica possui impacto que vai além do desperdício financeiro? 

Vamos imaginar essa divida técnica como sendo uma operação de crédito financeiro, e o nome Divida técnica como sendo a medida que o bureau de crédito da TI utiliza para controlar seu cadastro. Se não pagamos essa divida em dia, podemos ter nosso nome inscrito em um cadastro e como consequência sofrer limitações futuras.

> O serviço de proteção ao crédito, ou bureau de crédito, é um serviço de informações de crédito, que utiliza informações de adimplência e inadimplência de pessoas físicas ou jurídicas para fins de decisão sobre crédito.

Se você já teve nome sujo, bancos podem negar crédito para o resto da vida. Agora o mesmo pode acontecer com o não gerenciamento da dívida técnica. Como consequência, a velocidade de entrega do time é limitada. É possível contratar mais profissionais para fazer o mesmo trabalho. Em resumo, gastamos mais recursos financeiros para entregar menos funcionalidades. Duvida?


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mlf9tgvdgw0k9w2kziyu.png)

A lei de Brooks é uma observação sobre gerenciamento de projetos de software, segundo a qual adicionar mão de obra ao projeto de software que está atrasado o atrasa ainda mais. Foi cunhado por [Fred Brooks](https://en.wikipedia.org/wiki/Fred_Brooks) em seu livro de 1975 [O mítico homem-mês: ensaios sobre engenharia de software](https://www.amazon.com.br/m%C3%ADtico-homem-m%C3%AAs-ensaios-engenharia-software/dp/8550802530/).


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/hqx0ljdukyzteidhfq7m.jpg)

Se não é simples correlacionar o impacto financeiro com o bug, podemos analisar o impacto da dívida técnica na produtividade desses times. Pesquisas recentes sugerem que a empresa média perde 23-42% do tempo dos desenvolvedores devido a dívidas técnicas e código ruim em geral [1](https://dl.acm.org/doi/abs/10.1145/3524843.3528091). Outro dado interessante é que os desenvolvedores de software são frequentemente "forçados" a introduzir novas dividas técnicas à medida que as empresas mantêm a qualidade do código comercial para ganhos a curto prazo, como novas funcionalidades [2](https://research.chalmers.se/publication/511450/file/511450_Fulltext.pdf). 


A dívida técnica afeta tanto a felicidade dos desenvolvedores quanto a sua satisfação no trabalho [3](https://arxiv.org/abs/1904.08239). Nem sempre um profissional larga a empresa por motivos financeiros, existem outros fatores que precisam ser considerados. Além de perder um recurso, perde o conhecimento desse profissional, como mensurar o impacto financeiro dessa perda?


## Por que isso acontece?

Em mais de 13 anos de experiencia consigo listar essas desculpas como sendo as mais comuns:

> Não temos tempo para testar essa alteração, vamos colocar em produção e assim vamos monitorar o ambiente para saber o que vai acontecer.

> Existe um processo de gestão de mudança (GMUD), mas ele é tão complicado que se for seguido a próxima janela de implementação é só daqui 2 meses, e o cliente precisa dessa funcionalidade agora.

> O nosso ambiente de teste não esta atualizado ou não esta pronto. Isso quando não existe a resposta: o ambiente de teste é em produção (junto com nossos clientes).

Recomendo a leitura do livro  [O projeto fênix: um romance sobre TI, DevOps e sobre ajudar o seu negócio a vencer](https://www.amazon.com.br/projeto-f%C3%AAnix-Gene-Kim/dp/8550801895), esse livro não possui uma linguagem excludente, vulgo _techniques_, se trata de uma novela da área de TI. Um pouco da historia: O time de Operações de TI é olhado por todos como causadores de problemas, além de estarem sempre atrapalhando o andamento do Projeto Fênix, cujo objetivo é salvar a empresa. Como consequência não é possível alocar as pessoas certas da empresa em projetos estratégicos pois precisam apagar focos de incêndio, soa familiar?

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fbofesx7cxmdp5xzvup3.jpg)

## O papel da governança

Um estudo do [IDC](https://www.idc.com/research/viewtoc.jsp?containerId=US44640719) previu em 2019 que em 2022, 90% dos Novos Serviços Digitais serão construídos como aplicações compostas usando serviços públicos e internos fornecidos por API; Metade desses serviços irá alavancar a IA e o aprendizado de máquinas.

Se um desses serviços está com uma dívida muito alta pode criar um efeito cascata e prejudicar outros serviços. Seria algo assim...

<img width="100%" style="width:100%" src="https://media.giphy.com/media/URqZ9jDNRfunXPvVhE/giphy.gif">

Bem, importância de uma base de código saudável é amplamente subvalorizada no nível empresarial: mais de 90% dos gerentes de TI carecem de processos e estratégias para o gerenciamento da dívida técnica [4](https://www.infoq.com/articles/business-impact-code-quality/).

Agora para ter uma organização de alto desempenho, precisamos ser sensíveis às necessidades dos clientes, agir com base em feedback e continuar a inovar se quisermos permanecer relevantes no mercado. E precisamos fazer isso durante ciclos de produtos cada vez mais curtos. E para gerenciar essa dívida técnica é necessário uma área especializada e dedicada para fomentar estratégia focando nos processos, programa e pessoas capacitadas.