Comecei minha carreira em TI há uns 50 anos. Sim, quase meio século! E o que entusiasmou e continua me entusiasmando é o software. Com software, você pode criar soluções, novos negócios e até usa um hardware de forma que ele não tinha sido pensado para ser usado.

Desde o início procurei me aprofundar na lógica e construção de algoritmos e uma série de livros que me inspiraram foi “Art of Computer Programming” de Donald Knuth, uma das principais referências na ciência da computação e a Bíblia dos desenvolvedores nos anos 1970 e 1980, e creio que ainda muito atual! Infelizmente não os tenho mais, mas as ideias e conceitos continuam presentes no meu dia a dia profissional.

Ao longo dos anos, escrevi software em diversas linguagens, como Cobol, PL/1 e Assembler nos sistemas mainframe 370, Fortran (na academia), Lisp, no meu primeiro projeto de IA, no então modelo de “expert systems”, hoje carinhosamente chamados de GOFAI ("Good Old-Fashioned Artificial Intelligence"), depois um pouco em C e Java, e nos últimos anos uma pitadinha de Python.

Hoje não escrevo mais código. Mas, desde aquela época me interessava em não apenas em otimizar código, mas descobrir e entender novos modelos de engenharia de software que aumentassem a produtividade.

Em otimização lembro de um paper que li nos primórdios da carreira e me motivou a repensar a maneira de escrever código: “Go to statement considered harmful” de Edsger Dijkstra. Também na época, as limitações de memória dos computadores e a inovação da chamada memória virtual me chamaram atenção para pensar em como otimizar a programação nesses ambientes.

Um paper que me inspirou nisso foi “The Working Set Model for Program Behavior” de Peter J. Denning. A partir daí comecei a me aprofundar em conhecer mais a fundo as linguagens de programação e então devorei o “Compiler Construction”, que tem uma versão gratuita em PDF.

A tecnologia evolui continuamente e comecei a estudar novas formas de programar, como a programação modular, a “Object Oriented Programming” e a experimentar novas tecnologias como as ferramentas Case e as então chamadas linguagens de quarta geração como Natural e Power Builder.

Nesse processo tive que aprender a desaprender e a reaprender técnicas de programação, saindo da programação monolítica (com o velho modelo “waterfall”) na qual comecei, passando para a programação estruturada, Orientação a objetos e ao mundo dos métodos ágeis e das APIs de hoje.

Indiscutivelmente que software é o esteio da sociedade hoje. Sem chips e softwares um avião não decola, um automóvel não funciona, um banco fica paralisado, não temos energia nem telecomunicações. As empresas, em todos os setores, estão cada vez mais dependentes de software.

Sem chips e softwares um avião não decola, um automóvel não funciona e um banco fica paralisado

Não existem dados muito confiáveis, apenas estimativas, e uma delas, que me pareceu um pouco mais sensata fala em cerca de 6 milhões de desenvolvedores profissionais no mundo e se cada um escrever 60 linhas de código por dia, em 250 dias de trabalho (supondo que não “codem” nos fins de semana, o que em sempre é verdade...) serão cerca de 90 bilhões de linhas de código escritas por ano.

Exagero? Talvez, mas, na falta de outros, dados ficarei, por enquanto com esse número. Embora a engenharia de software exista a uns 60 anos, vamos imaginar que o desenvolvimento mais massivo aconteceu nos últimos 20 anos, e podemos estimar que já se escreveu mais de 1 trilhão de linhas de código no mundo.

Têm um gráfico interessante, de 2017, “How Many Millions of Lines of Code Does It Take?”, que mostra alguns dados interessantes, como por exemplo que uma aeronave moderna como o Boeing 787 tem 6,5 milhões de linhas de código em seus aviônicos e sistemas de controle embarcados.

Claro que linhas de código são métricas enganosas pois muitas vezes usamos bibliotecas já prontas e hoje reaproveitamos muito de repositórios como GitHub, sem necessidade de escrever muito código, mas o número serve como medida de grandeza.

Software hoje é parte do negócio. Qualquer empresa, de qualquer setor, depende em maior ou menor grau dos seus softwares para funcionar. Um banco sem software não faz nada. Uma operadora de celulares sem software não completa uma ligação. A energia não chega na nossa casa.

Assim, precisamos analisar o impacto dos softwares nas empresas. Um estudo, da McKinsey, é bem interessante. O “Developer Velocity: How software excellence fuels business performance” criou uma métrica, chamada de DVI (Developer Velocity Index)  que conseguiu correlacionar velocidade de desenvolvimento de software com resultados do negócio.

Por exemplo, o estudo mostrou que as empresas que se posicionaram no quartil superior apresentaram um crescimento quatro a cinco vezes mais rápido do que as pontuações DVI do quartil inferior. As empresas do quartil superior também têm maiores retornos para os acionistas (60%) e margens operacionais 20% maiores.

Além disso, as empresas do quartil superior parecem ser mais inovadores, com pontuação 55% maior em inovação do que as empresas do quartil inferior. Essas empresas também pontuaram mais positivamente em satisfação do cliente, percepção da marca e atração e retenção de talentos.

Mas existem sombras pairando sobre as empresas. É a chamada dívida técnica, um conceito de desenvolvimento de software que surgiu por volta do início dos anos 1990. O termo vem de uma metáfora inspirada no conceito de dívida existente na área de finanças e negócios, aplicada ao campo de software.

Um software desatualizado incorre em custos futuros, como em cartões de crédito: juros, a serem reembolsados ​​na forma de tempo adicional de manutenção e correção de bugs cada vez mais frequentes. A dívida técnica deve ser paga rapidamente para evitar o acúmulo de juros, daí a analogia com o conceito de dívida financeira.

 

Assim, como acúmulo de dívidas financeiras pode limitar as opções financeiras de uma pessoa ou empresa, a dívida técnica também pode sufocar o crescimento digital. Toda empresa tem algum grau de dívida técnica, o que retarda o progresso digital em vários setores.

Um problema é que a dívida técnica é difícil de ser identificada e mensurada. É como a parte submersa de um iceberg. Mas, alguns sintomas podem ser detectados, como atrasos frequentes no lançamento de produtos e serviços, custos crescentes de manutenção, reclamações cada vez mais intensas dos usuários dos sistemas e até mesmo pessoal técnico deixando a empresa demonstrando frustração.

Sistemas desatualizados podem afetar diretamente o resultado do negócio. Muitos sistemas estão com código desatualizado, estilo espaguete, que já está rodando há uns 20 anos ou mais e ninguém sabe como mexer nele. Cria-se camadas de software em cima das antigas. Aumenta-se a complexidade, com múltiplas gerações tecnológicas, nem sempre intercambiáveis tentando conviver na mesma organização.

Um recente estudo, também da McKinsey, “Demystifying digital dark matter: A new standard to tame technical debt”, mostrou números que chamam a atenção. Por exemplo, cerca de 30% dos CIOs que responderam à pesquisa acreditam que mais de 20% de seu orçamento de TI que seria dedicado a novos produtos é desviado para resolver problemas relacionados a dívidas de tecnologia. Além disso, eles estimam que a dívida de tecnologia seja de 20% a 40% do valor de todo o seu patrimônio tecnológico (antes da depreciação).

Altos níveis de dívida técnica, como altos níveis de dívida de cartão de crédito, alimentam a si mesmos, criando uma espiral descendente de esforços fracassados para modernizar a TI, resultando no aumento cada vez maior das dívidas de tecnologia. O estudo mostrou que empresas com alto endividamento têm 40% mais probabilidade de terem seus projetos de modernizações de TI incompletos ou cancelados, do que as com baixo endividamento. Ou seja, um alto grau de endividamento técnico é uma desvantagem competitiva.

Os impactos da dívida técnica podem ser muito grandes e até em um eventual processo de M&A diminuir o valor do negócio. É um tema abordado nesse artigo da Forbes, “McKinsey’s Tech Debt Solution Perpetuates CIOs’ IT Modernization Problem—Here’s Why Due Diligence Is A Better Idea”.

O que fazer? Se a empresa melhorar sua posição quanto a sua dívida de tecnologia vai ajudar a direcionar melhor recursos de tecnologia para iniciativas que aumentam a receita. A primeira coisa é reconhecer que existe uma dívida técnica. Isso significa que o CIO deve ser o mais transparente possível quanto ao problema diante do CEO e do conselho.

A transparência significa mostrar os custos da dívida de tecnologia e provar que essa dívida, se não for quitada, afeta e vai continuar afetando os investimentos em TI. O CFO e o CIO podem, então, concordar com as prioridades de alocação de recursos, que o CIO pode usar para desenvolver estratégias com suas equipes para lidar com a dívida de tecnologia.

A transparência significa mostrar os custos da dívida de tecnologia e provar que essa dívida, se não for quitada, afeta e vai continuar afetando os investimentos em TI

O uso adequado de novas tecnologias como geradores automáticos de código baseados em “generative AI” como GitHub Copilot, chatGPT, CodeWhisperer da Amazon e outros e plataformas low-code ajudam a diminuir essa dívida técnica. Elas motivam e incentivam as empresas a criarem aplicativos mais rapidamente, reduzindo a carga de manutenção constante de suas equipes de TI.

Isso ajuda a empresa a redirecionar recursos para a inovação, o que, por sua vez, ajuda a impulsionar o negócio. As plataformas low-code ajudam a liberar mais rapidamente a equipe de desenvolvimento do seu envolvimento com a dívida técnica e permitem que eles se concentrem em novos desenvolvimentos.

Em low-code, recentemente escrevi um ebook abordando sua implementação e disseminação nas empresas, mas sempre olhando a governança, para evitar a proliferação da chamada “shadow IT”, que poderá, se descontrolada, aumentar a dívida técnica. Para isso é sugerida a criação de um Centro de Excelência em Low-code, que pode ser baixado gratuitamente aqui.

Em resumo, monitore sua organização de TI e procure medir sua dívida técnica. Não é simples, mas também não se aprofunde em fórmulas e cálculos matemáticos. Uma estimativa já é suficiente para mostrar para a alta administração que a empresa está perdendo tração porque mantém sistemas obsoletos e não está priorizando adequadamente a evolução e modernização de seus processos e sistemas.

* Cezar Taurion é VP de Inovação da CiaTécnica Consulting, e Partner/Head de Digital Transformation da Kick Corporate Ventures. Membro do conselho de inovação de diversas empresas e mentor e investidor em startups de IA. É autor de nove livros que abordam assuntos como Transformação Digital, Inovação, Big Data e Tecnologias Emergentes. Professor convidado da Fundação Dom Cabral, PUC-RJ e PUC-RS.