Imagine que você é um cozinheiro que trabalha todos os dias numa cozinha bagunçada, com os ingredientes desorganizados, cheia de panelas sujas. Você não consegue encontrar facilmente os utensílios de cozinha de que precisa, e não tem espaço para preparar os ingredientes. Infelizmente, não há tempo para limpar e organizar a cozinha, e por isso você está condenado a trabalhar nesse ambiente terrível que torna o processo de cozinhar muito mais lento, difícil e estressante.

Essa é a mesma situação em que um desenvolvedor de software se encontra ao trabalhar em um software com uma grande quantidade de débito técnico. A bagunça desacelera o desenvolvedor e, às vezes, até o impede de fazer o trabalho real. Torna difícil sentir orgulho do trabalho que você está fazendo, pois muito tempo é perdido vasculhando e entendendo o código. Fora o medo de quebrar algo que esteja funcionando em produção.

O maior problema é que, ao contrário de uma cozinha suja, o débito técnico é em sua maioria invisível para nossos stakeholders. Eles só podem ver o efeito de desaceleração que ela causa, mas quando o fazem muitas vezes já é tarde demais. Tudo se resume a novos recursos constantemente adicionando novo código em bases já frágeis.

Outro problema é que uma quantidade excessiva de débito técnico coloca os desenvolvedores no modo de combate a incêndios. O débito técnico afeta toda a empresa, mas para os desenvolvedores, mais dívida técnica significa mais bugs, mais problemas de desempenho, mais tempo de inatividade, entregas lentas, falta de previsibilidade nas iterações e menos tempo gasto construindo coisas novas.

Os programadores gastam sete horas por semana em débito técnico.

Um estudo da Microsoft publicado em 2017 concluiu que 58% do tempo dos desenvolvedores é gasto na compreensão do código, especialmente quando o software é enviado para produção e precisa ser mantido. É algo que os desenvolvedores reconheceriam intuitivamente: quanto menos familiarizado você estiver com o código, mais tempo levará. Quanto mais surpresas surgirem no caminho, mais tempo levará. Quanto mais difícil for reproduzir todos os cenários, mais tempo levará para acertar, e é aí que os bons testes automatizados realmente se destacam.

Ler código é mais difícil do que escrever código. Uma grande quantidade de débito técnico muitas vezes significa que você tem mais código para ler, e o código é mais difícil de entender. A dívida técnica também significa que os desenvolvedores geralmente entenderão partes menores do sistema sem ver o quadro geral.

O tempo perdido resolvendo esse problema muitas vezes é invisível para os stakeholders, e o ganho de produtividade é invisível até que outra alteração seja feita. Uma cozinha limpa não acelera você até que você precise cozinhar nela. O ganho de produtividade não é óbvio e na maioria das vezes não recebemos tempo extra para resolver débito técnico.

Os desenvolvedores podem entregar mais rápido se controlarem o débito técnico.

Controlar o débito técnico é um requisito para entregar valor regularmente, da mesma forma que uma cozinha organizada e limpa é um requisito para servir comida deliciosa regularmente. Isso não significa que você não terá dívida técnica. Sempre haverá alguma bagunça, e isso também é saudável. O objetivo não é ter zero bagunça, e sim se livrar da bagunça que o desacelera e impede você de administrar uma cozinha excelente.

A bagunça nem sempre é ruim. Às vezes, a bagunça também é necessária para manter o fluxo. Quando você está fazendo algo novo, como montar um guarda-roupa, você fará bagunça enquanto monta. Se você imediatamente limpar essa bagunça enquanto está ocupado trabalhando, perderá todo o seu ritmo. Trata-se de corrigir a quantidade certa de dívida técnica no momento certo.

Lidar de maneira mais eficaz com o débito técnico é fundamental. Isso significa não estender a mesma preocupação com o débito técnico em áreas do software que raramente são usadas ou alteradas. Isso também significa que os desenvolvedores não deveriam precisar justificar a correção da dívida técnica. Assim como limpar a cozinha faz parte do processo de cozinhar, corrigir a dívida técnica faz parte do processo de codificação.

Quantas vezes você estimou que um recurso levaria um sprint e acabou levando dois ou três? Agora imagine isso na escala de uma empresa inteira e as ramificações que isso teria. Não é difícil acreditar que desenvolvedores que realmente têm um bom controle do débito técnico entregam o dobro da rapidez em comparação com aqueles que não têm.

Prós e contras de lidar com débito técnico continuamente.

Lidar com o débito técnico continuamente é fundamental para a maioria das empresas, especialmente aquelas que alcançaram o ajuste de mercado e têm como objetivo entregar software de qualidade aos seus clientes. Não é sempre fácil de alcançar e existem pontos positivos e negativos nesta abordagem.

Prós:

  1. Entrega de valor contínuo. O trabalho contínuo de manutenção do débito técnico é um pré-requisito para entregar valor regularmente.
  2. Satisfação dos desenvolvedores. Ninguém gosta de trabalhar na bagunça.
  3. Agrega valor ao negócio. Pois diminui o tempo de lançamento de novos recursos no software.
  4. Não precisa de permissão. Se você for proativo e limpar o código, não precisará solicitar um orçamento para isso. Isso faz parte do trabalho, você é o especialista.
  5. É mais fácil começar. É possível começar melhorando pequenas partes do software e ir avançando ao longo do tempo.

Contras:

  1. É mais difícil abordar grandes partes de dívida técnica que se acumularam ao longo do tempo. No entanto, uma vez que a equipe tenha experiência suficiente, eles encontrarão uma maneira de dividir o trabalho em partes menores.
  2. É extremamente fácil deixar que as pressões normais do negócio interrompam o trabalho de manutenção contínua do débito técnico.
  3. A manutenção contínua do débito técnico é invisível e não gera elogios. A vantagem é que você não precisa pedir permissão e não precisa trabalhar muito para apagar incêndios.

Como reduzir o débito técnico.

Conforme a indústria amadurece, continuaremos elevando a barra de qualidade. Escrever software mantível é difícil. É um desafio para as empresas principalmente quando a rotatividade de desenvolvedores é inferior a dois anos e desenvolvedores mais experientes deixam de codar por algum motivo.

Algumas dicas podem ajudar a melhorar a situação se você tiver muito débito técnico:

  1. Tone-o visível, evidencie o débito técnico e depois você pode começar a enfrentá-lo. Ambiente de Integração Contínua e ferramentas de análise estática do código podem ser seus melhores amigos nesse processo.
  2. Seja proativo e incentive a equipe a fazer o mesmo. Comece nas pequenas coisas, melhorando nomes de variáveis, funções ou classes. Extraindo métodos, ou quebrando métodos grandes em menores. Aplique a regra do escoteiro sempre!
  3. Fale com stakeholders usando termos de negócio. Não abordamos a dívida técnica por capricho, mas porque queremos entregar recursos mais rapidamente. “Queremos reduzir nosso time-to-market” ou “Poderíamos reduzir nossa rotatividade se investíssemos tempo na qualidade do código”, entre outros exemplos. Pontos extras se você puder obter números reais com base em fatos. Pontos extras se você puder vinculá-lo ao dinheiro: “Nos últimos três meses, gastamos 42% do nosso tempo de desenvolvimento na correção de bugs, o que nos custou 1 milhão de reais”.

Os programaores devem se esforçar para abordar proativamente e continuamente o débito técnico. A única maneira de fazer isso é por meio de refatoração. Organizações ágeis estão constantemente aprendendo e evoluindo. Se não investirem na melhoria contínua de seus códigos, seus códigos permanecerão estáticos e se tornarão um passivo pesado em questão de dias.

Investir na melhoria contínua do código levará a menos bugs, menos tempo de inatividade, menos solicitações de suporte, entregas mais previsíveis e rápidas, e programadores mais felizes (e retidos).