Pare de ignorar dívidas técnicas (e o problema do astronauta de Marte)

Frequentemente enquanto você trabalha com desenvolvimento de software, você se depara com um trecho de código mal escrito, está propenso a erros e pode causar queda de performance da funcionalidade que você está trabalhando ou até de todo o sistema. Se você é um desenvolvedor de software, tenho certeza que isso soa familiar prá você. A esses códigos ruins damos o nome de "Dívidas Técnicas", formalmente falando, ou "Janelas Quebradas" de acordo com a ilustração de Andy Hunt e Dave Thomas no livro "O Programador Pragmático". Nós nos acostumamos com janelas quebradas, nós as vemos todos os dias, conseguimos reconhecê-las muito facilmente, mas frequentemente nós não concertamos elas. Existem muitas razões para que não concertemos elas: "nós vamos atrasar o projeto", "essa refatoração não tem valor de negócio, então você deveria trabalhar nessa estória que tem mais prioridade", "a refatoração precisa de muito trabalho", etc

Mas me acompanhe em um exemplo: imagine que você esteja trabalhando em um novo lançador de foguetes para a NASA (ou qualquer outra agência espacial). Você é responsável pelo cálculo do ângulo de partida do foguete quando deixar a Terra. Você usou TDD, todos os testes foram muito bem escritos e aceitos, os engenheiros ficaram felizes então é tranquilo implantar o sistema em produção. A agência espacial planeja enviar duas pessoas para Marte em uma janela de tempo bem específica, quando o Universo estará alinhado para um lançamento certeiro. Então o foguete com esses dois astronautas malucos decola, e tudo vai bem nas primeiras duas semanas depois da nave deixar a Terra, de repente você percebe algo estranho: a nave está desviando, não chegará a Marte. "Mas o que deu errado?", você pensa. "Todos os testes passaram, os engenheiros confirmaram os resultados, tudo parece perfeito. Eu não consigo entender". Então você revisa o código, tudo parece bom. Você pega a sua calculadora preferida e faz todos os cálculos na mão e compara com os resultados do algoritmo. Você sente um arrepio na espinha: o resultado dos seus cálculos foi 36°34532923', e desenhando essa rota em um mapa espacial, é o ângulo certo; mas o resultado do algoritmo foi de 36°34533'. Está arredondando para 5 pontos decimais! Minha nossa! Em uma viagem espacial, conforme o tempo avança, esse valor pode enviar as pessoas na nave para outra galáxia.

Tudo bem, esse é um exemplo intencionalmente ridículo e exagerado. Mas funciona para ilustrar meu ponto de vista: com o passar do tempo, fica cada vez mais difícil concertar uma dívida técnica. Se você pensar no exemplo do lançador de foguetes, perceberá que à medida que a nave se distancia da Terra, a distância entre o caminho certo e o caminho que ela está fazendo vai aumentando dramaticamente. Essa é o meu ponto. Quando ignoramos janelas quebradas ou deixamos para consertá-las quando tivermos "tempo livre", talvez a distância será tão grande que você não terá mais como consertar, depois que o time inteiro alterou esse código, adicionando mais e mais complexidade a ele. Então você percebe que o conserto tomará muito tempo, exigirá muito trabalho, e o cliente não pagará por isso (o que faz sentido, uma vez que isso não adicionará nenhum valor de negócio ao produto).

Dessa forma, nós devemos parar de ignorar nossas dívidas técnicas. Nós precisamos tentar negociar o conserto com os product owners o mais cedo possível. Não por que gostamos de código bem escrito (sim, claro, por causa disso também), mas mais importante que isso, queremos entregar um sistema robusto que terá uma vida longa e feliz. ;)

Então, meus dois centavos: pare de ignorar dívidas técnicas, pare de ignorar dívidas técnicas e o mais importante, pare de ignorar dívidas técnicas.