Dívida Técnica: O que é, como surge e como resolver

Já tem um bom tempo que não falo sobre assuntos técnicos por aqui. No entanto, outro dia tivemos que pagar uma dívida técnica bem alta e isso acendeu alguns alertas. Os produtos dos meus times sofrem atualizações constantes seja por manutenção, pedidos de evolução, segurança ou adequação legal e tudo funcionava bem, porém tivemos um pequeno desafio nos últimos meses.

O problema que evidenciou a necessidade de falar sobre Dívida Técnica

Se você trabalha com Java para web, já se ligou que houve uma atualização significativa dos pacotes javax para jakarta. Já aconteceu há algum tempo, mas temos aplicações sensíveis e isso atrasou um pouco a migração.

Quando migramos, o tempo e os problemas começaram a aparecer e alguns rollbacks (volta para a aplicação inicial). Foi bem chato e ainda estamos trabalhando nisso.

O que é Dívida Técnica

Dívida técnica é o acúmulo de deficiências estruturais, tecnológicas ou de qualidade em um software que, se não tratadas, dificultam sua manutenção, evolução e confiabilidade. Ela pode surgir tanto por fatores internos de decisões conscientes ou inconscientes do time quanto por fatores externos, como mudanças tecnológicas ou de negócio.

Tipos de Dívida Técnica

Existem 4 tipos básicos de dívida técnica. Os dois primeiros se originam do próprio time e os outros dois de fatores externos.

Intencional

O time sabe que está criando dívida para ganhar velocidade agora, com plano de pagar depois (pelo menos é o que se espera).

Acidental

Fruto de falta de conhecimento, experiência ou negligência.

Obsolescência Tecnológica

Após a 1ª entrega, o produto já se torna um legado que deve ser mantido pelo time. Se ninguém mexer nele, fatalmente ele ficará preso a tecnologia, bibliotecas e servidores desatualizados. Além de ficar mais inseguro a cada dia que passa.

Mudanças do Ambiente

Outra coisa que pode acontecer é o ambiente em que o produto está inserido mudar. Novas leis, mudanças do consumidor, alteração de gestores, mudanças da estratégia ou novos concorrentes, podem inutilizar o produto.

Conhecendo os tipos de dívidas técnicas, agora aproveito para apresentar como elas surgem. Essa não é uma lista exaustiva, mas dá uma boa ideia sobre as principais fontes.

Fontes internas de dívida técnica (incidentais ou acidentais)

Neste tópico coloco aquelas origens que acontecem dentro do time e normalmente cabe a ele resolver. Como são muitas, subdividi em temas.

Codificação

São as fontes que surgem por decisões de escrita do código-fonte da aplicação.

Solução rápida

Muitas das vezes precisamos dar uma resposta rápida, seja porque o prazo para a entrega foi muito curto, urgência, aproveitar uma oportunidade emergente. A solução rápida nem sempre é a melhor. Ela resolve o problema pontual, porém pode impedir o crescimento do produto.

Quick fixes recorrentes

Muitas vezes para resolver um problema na codificação, nós precisamos de semanas ou até mesmo meses. Por esse motivo, muitas equipes partem para o modo “consertinho” fazendo pequenas manutenções ao longo do tempo. Infelizmente, ao invés de resolver o problema, podemos colocar probleminhas em torno dele e criar um problemão.

Dirty Code (código sujo) ou Code Smells (código fede)

As boas práticas de codificação (clean code) ajudam a ter um código legível e fácil de evoluir. Quando são ignoradas, o código-fonte fica “sujo”, as manutenções ficam difíceis e temos grandes chances de ficarmos à mercê do programador, pois só ele entende o que fez.

Código gerado por ferramenta

Muitas ferramentas geram código-fonte. Lembro de usar o Microsoft Publisher em 1995 e ele criava uma aplicação web bem bonita para a época. O problema era a qualidade do código-fonte. Um emaranhado de coisas que faziam funcionar, mas alterar qualquer coisa e dar manutenção naquilo era praticamente impossível. Avançando para hoje, temos diversas ferramentas Low Code e IAs que geram aplicações inteiras como o lovable.dev e Canva Code. Elas já escrevem um código muito mais limpos do que as ferramentas do período neolítico 😁, mas ainda assim, não é tão fácil dar manutenção nele.

Dívida de Experiência de Usuário (User eXperience) / Interface do Usuário (User Interface)

Uma tela confusa tende a ficar mais confusa conforme o tempo passa, pois nós tendemos à complexidade. Interfaces confusas, não responsivas ou inconsistentes com os padrões modernos de usabilidade pioram a experiência do usuário.

Qualidade

Dívida técnica gerada pela falta de qualidade ou governança durante a criação do software.

Falta de testes automatizados

Testes são sempre bem-vindos, porém fazê-los de forma manual em um produto grande é quase impossível. Se você está na Sprint 30, dificilmente testará as funcionalidades entregues na Sprint 1. Além disso, você testará todo o produto que foi construído há dez anos e que vem sofrendo manutenções desde lá? A resposta é não. Portanto, você precisa de testes automatizados. Eles garantem que o produto seja testado toda vez que haja qualquer alteração nele.

Ausência de monitoramento

Imagina que quando foi lançado o produto possuía dez usuários. Agora, alguns anos depois, ele está com mais de um milhão de usuários. Tudo o que funcionava bem no início, provavelmente não está funcionando mais. O time não pode ser pego de surpresa pela mensagem de que acabou a memória, espaço em disco etc. Por isso o monitoramento do software é fundamental.

Falta de governança de código compartilhado

Módulos ou bibliotecas internos que são utilizadas por vários times, mas não têm donos definidos. Quando alguém precisa fazer alguma mudança nele, pega, altera e resolve o problema para o seu time enquanto para de funcionar para todos os outros.

Documentação

Ela é necessária e muito útil, porém os extremos devem ser evitados.

Falta de documentação

Eu sei, pode ser chato fazer, mas você já pegou um software e ficou tendo que espalhar dezenas de breakpoints para ver que cargas d’água estava acontecendo. Ou então abriu uma procedure do banco de dados e se deparou com mais de 2000 linhas de código. A documentação não precisa ser extensiva, contudo, não pode ser nula. Ela deve ser suficiente para que qualquer pessoa possa dar manutenção e evoluir o produto no futuro.

Excesso de documentação

Parece que estou sendo contraditório, porém juro que não estou. Uma vez fui começar a trabalhar em um projeto e me entregaram um DVD com a documentação dele. Achei que havia sido um exagero, mas quando fui olhar,  os 4,7 GB estavam quase lotados. Havia de tudo, desde documentação de código, documentos do PMBOK e até a conversa das pessoas na ferramenta de troca de mensagens. Na prática, ficávamos perdidos quando precisávamos de qualquer informação, acabávamos recorrendo à leitura do código e aos famosos breakpoints.

Ferramentas inadequadas

Uma vez trabalhei em uma empresa que insistia que toda documentação deveria ser feita em documentos do MS Word. A justificativa era que a empresa utilizava várias linguagens de programação diferentes e o Word era um “artefato comum” a todas elas. Eles inclusive compraram uma ferramenta para orquestrar tudo isso. O problema é que cada linguagem já tem o seu padrão de documentação. Por exemplo, o Java tem o Java Doc, o Python o Pydoc. Como os desenvolvedores tinham que sair da sua ferramenta, abrir o Word e começar a documentar o código lá, adivinha o que aconteceu? A documentação descrevia um barquinho de papel e o software implementado era um navio transatlântico.

Arquitetura

Arquitetura incipiente

Uma coisa que já esbarrei bastante, foram novos times tendo que definir uma arquitetura do zero toda vez que iniciavam um novo projeto. Isso tende a piorar quando temos excesso de rotatividade de pessoal ou excesso de terceirização. Cada um tem uma ideia e cada arquitetura é definida no momento, ad hoc. No final, não há padrão de nada e toda mudança é dolorosa. Migrações de tecnologia são quase impossíveis, pois cada uma terão que ser feitas de forma isolada.

Otimização prematura

O extremo oposto da arquitetura incipiente é a otimização prematura da arquitetura. Tem um vídeo muito interessante  do Prof. Eduardo Guerra sobre esse assunto. Basta lembrar das avenidas na Coreia do Norte. São 5 pistas para cada um dos dois sentidos e por ela passam apenas algumas poucas bicicletas. 

Já tive um debate longo com um time de arquitetura que queria fazer algo que suportasse comunicação via: telefone, Whatsapp, e-mail, Twitter (atual X), Telegram, Facebook Messenger, Skype (que Deus o tenha). Sendo que 85% dos clientes só se comunicavam via Whatsapp, 10% por telefone e 3% por e-mail. Enquanto isso, todos os times estavam travados esperando a liberação da incrível arquitetura que teria que atender tudo até os 2% dos clientes que utilizam diversas ferramentas. 

Processos

Falta de processos

O famoso Go Horse. Chega uma demanda, bora resolver (antipadrão Wolf) e seja o que Deus quiser. Isso demonstra uma empresa “gasosa” em que os resultados são aleatórios. Por vezes funciona, às vezes não. Quem vai saber?

Processos Inadequados

Uma vez eu estive com um time que desenvolvia hardware. Ao contrário de software, que possibilita fazer mudanças significativas de um dia para o outro, no hardware isso não era verdade. As pessoas queriam fazer reuniões diárias (Scrum Daily) porque era o que estava no guia do Scrum. Como resultado, virava só uma repetição da mesma coisa todo o dia. Os técnicos podiam gravar a fala e apenas tocá-la no dia seguinte, pois não havia mudança alguma. Vendo isso, nós propomos algo semanal e aí sim a coisa fluiu.

Priorização incorreta

Esse aqui dispensa comentários, pediu mal, ganhou mal. Se a priorização for inadequada, teremos menos tempo para construir o essencial. Muitas das vezes, priorizamos pelo que é mais fácil desenvolver e ficamos apertados com prazo para implementar o que realmente resolve o problema do cliente. Logo, recorremos à solução rápida e quick fixes para tentar entregar algum valor.

Ciclos de Entrega Longos

Se você leva meses para poder colocar o produto em produção, chances são de você ter dívidas técnicas escondidas ao longo desses meses. Quando você finalmente lançar, a cobrança virá toda em uma única tacada.

Organização dos times

Desalinhamento interno

Se o time não trabalha como um time, podemos ter vários “lobos solitários”. Cada um dando a sua ideia e resolvendo o problema do seu jeito. Na hora de juntar tudo, a coisa vira um caos. Além do que, é natural que os membros do time mudem, pois pessoas chegam e outras vão embora. Se não houver alinhamento e padronização, a evolução será muito, muito difícil.

Desalinhamento com as dependências externas

Neste ponto, quando não há alinhamento, a coisa pode ser ainda mais caótica. Um time tem a dependência externa e se eles não fizerem acordos, cada um terá sua prioridade. Algo que é urgentíssimo para o Time 1 pode ser irrelevante para o Time 2. É aqui que a coisa inteira desanda porque é provável que o Time 1 faça soluções rápidas “de contorno” (vulgo gambiarra) que cobrarão seu preço no futuro.

Débito de conhecimento

Acontece quando todo o conhecimento sobre o sistema está depositado em  uma única pessoa ou em poucas pessoas. Se a pessoa sair da empresa, ela levará consigo todo o “manual” do produto.

Shadow IT / Soluções Paralelas

Softwares e integrações feitos por áreas de negócio sem envolvimento da TI (nas sombras). Um belo dia, alguém pede para a TI tomar conta daquela solução e o caos começa. Falta de segurança, falta de versionamento, despadronização e dívidas que nascem invisíveis. Um exemplo comum foram os “bancos de dados” em MS Access que inundavam as empresas nos anos 90/2000.

Obsolescência Tecnológica

Uma vez que já vimos as fontes de dívida técnica que estão dentro do time, podemos partir para aquelas que independem dele. A obsolescência tecnológica é uma dívida involuntária. A simples passagem do tempo e evolução do produto de terceiros se encarregam de reforçá-la.

Bibliotecas, frameworks e linguagem de programação ultrapassadas

Software é um ativo e como tal, deprecia. Quando comecei a desenvolver, você seria uma pessoa de destaque se soubesse programar para web com JSP + VB6 ou Java 1.4. Hoje isso é história de museu. Se demoramos muito para atualizar os componentes de uma aplicação, é possível que chegue um dia que ela não mais funcione e tenhamos que migrar tudo na marra.

Essas atualizações são, normalmente, de responsabilidade do próprio time. Logo, eles devem lembrar que software é igual a filho. Depois que colocou no mundo, tem que ajudar na evolução dele. 

Atualização de servidores, sistemas operacionais e componentes externos

Isso aqui normalmente depende dos times de infraestrutura. Por vezes é necessário atualizar a infraestrutura e isso pode trazer problemas para as aplicações que dependem dela. É importante que os times de desenvolvimento não sejam pegos de surpresa e tenham tempo para adequar suas aplicações. Entretanto, por outro lado, esse tempo não pode ser infinito, pois a infraestrutura precisa ser atualizada. Mais uma vez é importantíssimo o alinhamento dos times.

Vulnerabilidades

Elas são interessantes porque não dependem de ninguém da organização. Basta você deixar o software lá, paradinho, que as vulnerabilidades surgem. Sejam nas bibliotecas que o software utiliza, novas estratégias de invasão e fraquezas advindas da arquitetura da organização ou dos clientes. Basta ver como o banco da Common Vulnerabilities and Exposures (CVE) cresce diariamente.

Mudanças de Ambiente

Aqui são as fontes de dívida que não estão ligadas à tecnologia propriamente dita e sim às mudanças que ocorrem no entorno.

Alteração legal

Leis mudam e o produto que antes resolvia o problema pode passar a cometer uma ilegalidade. Por outro lado, pode acontecer o oposto. Uma solução que o time gostaria de implementar, porém não podia fazer porque não havia respaldo da legislação passa a ter. 

Rotatividade de pessoal

Esse aqui é o inferno do gerente ou Scrum Master. O conhecimento se vai a cada demissão e o time está em um estado eterno de formação. Sempre lembro de uma conversa que eu tive com o pessoal do RH do UOL. Segundo eles, se você contratar uma pessoa sênior, levará no mínimo seis meses até ela começar a desempenhar seu papel de sênior, pois a aculturação leva tempo para acontecer (acessos, entender a empresa, propósitos, tecnologia, processos, o problema que o time trata etc.).

Excesso de Terceirização

Já estive em uma empresa em que os membros de um time de dez pessoas era terceirizado por três empresas diferentes. Porém, o problema era ainda pior, pois os contratos acabavam em tempos distintos e nem todos se renovavam. A terceirização em si não é algo ruim, mas se não for bem feita você pode acabar com um software que é um monte de pedaços que não se integram ou o fazem com muita dificuldade.

Também já dei consultoria em outra empresa em que todo o time de desenvolvimento era terceirizado. A terceirizada saiu e outra ganhou o contrato e você já pode imaginar o tamanho do problema. Imagina pegar um software sem que ninguém da construção estivesse presente. O resultado foi que tiveram que contratar um dos programadores originais a peso de ouro e reduzir o custo contratando júniores para compor o restante do time. Parecia um sábio monge chinês com seus aprendizes shaolins.

Rigidez de processos

Por vezes, alguns times sofrem com a rigidez de processos. Mudanças se tornam necessárias, importantes, urgentes e essenciais. Porém para fazer qualquer mudança, são necessárias 200 autorizações e pedir bênção a 500 pessoas. É um contraponto à falta de processos, classifico como problema de ambiente, pois mudar isso, dificilmente dependerá do time. É perceptível que a falta de processos a empresa se torna “gasosa”, na rigidez de processos, ela se solidifica e não consegue fluir.

Como pagar a dívida técnica e evitar que ela se torne impagável

Aqui nós podemos separar em 2 formas de tratar a dívida técnica.

Tratamento preventivo

É um tanto óbvio, mas a melhor forma de pagar uma dívida é não fazê-la. Se fizer, que você tenha saldo suficiente para pagar. Assim é o tratamento preventivo da dívida técnica, vamos evitar que ela aconteça, mas se acontecer, possamos tratar com facilidade.

Estudo

Não precisa ser um gênio, mas quanto mais você estudar, mais preparado estará para evitar entrar na dívida ou pelo menos mais apto a pagá-la o quanto antes. Clean Code, como priorizar, como desenvolver o processo de trabalho, melhores práticas etc. 

Se precisar de ajuda, conte a K21.

Manter o software atualizado

Sempre que possível, mantenha o produto atualizado com pacotes, bibliotecas, frameworks e práticas de clean code. Sei que falando assim parece fácil, mas na prática nem tanto. Normalmente, assim que encerramos um projeto já somos alocados em outro e aquele vira um legado. Uma prática que temos é que em toda manutenção de produto tentamos atualizar as dependências (pacotes e bibliotecas) até o limite da compatibilidade.

Esse limite da compatibilidade é quando a próxima alteração das dependências é incompatível com o que estamos utilizando. Se alterar, será necessário fazer grande modificação do código-fonte. Por exemplo, imagine que o seu software utiliza a biblioteca 2.1, porém já existe a 2.2 e a mais recente é a 3.1. Tradicionalmente, a mudança da major version (primeiro número) indica que componentes antigos foram removidos e a forma como a dependência trabalha mudou. Nesse caso o limite da compatibilidade é a versão 2.2. Se atualizar para a 3.1, será necessário alterar o código da aplicação também.

Manter a infraestrutura atualizada

Não adianta manter apenas o software atualizado, pois a infraestrutura que suporta também deve estar atualizada. Servidores, sistemas operacionais, máquinas, banco de dados etc. Quando isso não ocorre, podemos chegar em um ponto de ruptura, seja por motivos de segurança ou de suporte e atualização. Imagine que você utilize um Windows Server 2016 que não tem mais garantia, suporte e atualizações. Por causa disso, você terá que realizar uma mudança drástica para o Windows Server 2025. Muita coisa vai parar de funcionar. Idealmente você deveria ter feito todas as atualizações entre 2016 e 2025 para que os softwares precisassem de pequenas manutenções diluídas ao longo de quase 10 anos.

Adequação dos processos

Você já sabe, mas não custa lembrar que o processo atende às necessidades do time, clientes e empresa,  nunca o contrário. Não crie um processo ultra complexo só porque algum livro disse para fazer. Estabeleça o mínimo necessário para o funcionamento e depois vá evoluindo aos poucos. Dê uma olhada no artigo “Quais as principais diferenças entre mudança revolucionária e mudança evolucionária: Kaizen vs. Kaikaku” que aborda esse tema.

Usar softwares de apoio

Hoje um software vai muito além da linguagem de programação e banco de dados. Você tem uma série de outros produtos que te ajudam a evitar dor de cabeça. Abaixo coloco a stack que utilizamos e alguns que já experimentei e curti muito. 

Tratamento Corretivo

Bem, o problema aconteceu, incorremos em dívidas e agora temos que pagá-las. Algumas possíveis soluções são:

Sprints “Técnicas”

Colocar no seu processo Scrum algumas sprints exclusivas para ajustes técnicos. Na teoria parece bom. Quantas vezes eu já as vi funcionar bem? Exatamente zero. Ou a sprint técnica é interrompida por alguma necessidade de negócio ou correção de erro ou então o time ouve “sprint técnica” e acha que ela tem três vezes o tamanho da sprint normal. Logo, é uma solução, mas nunca vi nenhuma que comece e acabe bem.

Balanceamento entre itens de negócio e itens técnicos

Para mim é o que funciona melhor, no seu fluxo de trabalho ter itens técnicos (que abatem a dívida) e itens de negócio (que, dependendo de como estão sendo concebidos, podem até aumentar a dívida). Sobre isso, já escrevi o artigo: Como tratar e priorizar itens técnicos?

Inteligência Artificial

Esse está muito ligado à execução. Vou dar um exemplo que aconteceu com nossos times. Um deles teria que migrar o componente Hibernate da versão 4 para a 6 (grande salto). Algumas coisas pararam de funcionar e nisso contamos muito com as IAs. O prompt foi: “Estamos migrando uma aplicação que roda em container baseado em Tomcat 9 com JDK17 para o Tomcat 10.5 em JDK 21. Estamos com um problema na migração do Hibernate. Pode nos ajudar?”
Copiamos e colamos as configurações do Hibernate (sem a senha) e o pom.xml. E a conversa começou daí. Basicamente o time copiava parte do código e os erros, colava na IA e ela resolvia o problema. Acredito que hoje, não é possível superar a performance de um time que trabalhe com IA para facilitar a programação.

Agentes de IA

Algumas coisas são chatas e repetitivas de fazer. Mesmo porque você terá que fazer a mesma coisa em diversos sistemas diferentes. Para isso, você pode criar agentes de inteligência artificial que acessam o seu código e fazem as substituições por você. Escrevi o artigo: Agente de Inteligência Artificial um tutorial para criar e usar o seu próprio robô virtual. Se quiser, temos alguns para migração do framework de teste Hamcrest para AspectJ, um cara que coloca equals(), toString() e hashCode() em classes de negócio.

Conclusão

Neste texto falei um pouco sobre o que são as dívidas técnicas, como elas surgem e como podemos tratá-las. Em resumo, espero que lhe seja útil e se você quiser conversar sobre isso, me procure lá no LinkedIn e…

Ci vediamo la prossima volta