Como eu aprendi sobre “dívidas técnicas”

O ano era 2001 ou 2002. Não lembro ao certo. Eu era um jovem programador, pai recente, tentando “encontrar meu lugar ao sol”

Estava trabalhando em uma feature importante para o Promob 4i, na época, escrito predominantemente em VB6 – a possibilidade de realizar subtrações (furos) em formas livres que chamávamos “geometrias” – e, por muitas razões, simplesmente não conseguia concluir minha tarefa. Meu atraso estava segurando o lançamento do produto e, embora eu me esforçasse muito, as “coisas não andavam”.

Como aconteceu mais de uma vez em minha carreira, eu estava literalmente, paralisado por análise. Nenhuma implementação que eu iniciava “parava de pé”, pelo menos segundo minha avaliação e, levando ao pé-da-letra a recomendação de que “código ruim não se remenda, se reescreve”, apagava tudo e começava do zero o tempo todo – para desespero do meu “chefe comercial”.

Aliás, as coisas ficaram tão sérias que, um dia, esse “chefe comercial”, retornando de viagem, trouxe consigo um “santinho” com a imagem de Santo Expedito – o santo das causas urgentes e impossíveis. Por brincadeira, ele fixou o “santinho” na minha “baia de trabalho” e disse que eu somente poderia tirá-lo de lá quando concluísse minha tarefa.

Como o “comportamento do chefe”, principalmente o ruim, é sempre seguido pelo time, toda vez que alguém da área comercial saia para a rua, voltava com mais um “Santo Expedito” para decorar o lugar onde eu trabalhava tornando-o quase um altar para o dito santo. Eu, obviamente, “acusei o golpe”.

Importante deixar claro que, embora a atitude do meu chefe seja condenável e repreensível, os tempos eram outros. Além disso, éramos amigos e tínhamos liberdades.

Para me livrar dos “santinhos”, embora não tenha nada contra Santo Expedito, aprendi a assumir dívidas técnicas. Explico: entendi que, muitas vezes, é mais importante entregar algo e rápido, mesmo que não da forma perfeita, para, no futuro, voltar e “arrumar as coisas”, do que tentar uma implementação perfeita que, provavelmente, nunca ficará pronta.

Lembro-me que a implementação que considerava inferior funcionou bem por anos sem “cobrar juros” de nenhuma espécie. Era relativamente fácil de manter, tinha boa performance e satisfazia plenamente os requisitos.

Essa experiência me ensinou três lições importantes:

1. assumir dívidas técnicas é uma habilidade importante para superar desafios importantes como, por exemplo, a paralisia por análise;
2. nem tudo que parece dívida técnica, de fato, é;
3. Santo Expedito tem poder. 😉

Até hoje, toda vez que preciso assumir uma dívida técnica, escrevo ou falo sobre o tema, lembro do santo das causas urgentes. Para mim, padroeiro dos programadores com tarefas atrasadas.

Já falamos nos “Drops da EximiaCo” sobre o fato de que “Nem tudo que parece dívida técnica, efetivamente, é“. Confere lá.