É 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?
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: O criador do algoritmo QuickSort e também vencedor do Prêmio Turing (o Prêmio Nobel de Computação) acrescentou uma funcionalidade simples na linguagem 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, 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, inventor of ALGOL W.
Pode encontrar nesse link 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?
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 em seu livro de 1975 O mítico homem-mês: ensaios sobre engenharia de software.
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. 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.
A dívida técnica afeta tanto a felicidade dos desenvolvedores quanto a sua satisfação no trabalho 3. 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, 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?
O papel da governança
Um estudo do IDC 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...
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.
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.
Top comments (1)
Lembrei disso!