Débito Técnico

Se você já trabalhou em algum projeto ágil, com certeza você sabe muito bem sobre o que este post irá tratar, porém, se você ainda não tem muito conhecimento em processos (ágil principalmente), comece por aqui.

Vamos falar de uma coisa bastante polêmica; odiado por uns, defendido por outros e está bastante relacionado com projetos ágeis, o porquê de tudo isso? Veremos.

Veremos, como é fazer uma dívida com o nosso próprio código, isso é bom ou ruim e onde se aplica?

O que é

A definição de débito técnico segundo techopedia (tradução literal): é um conceito em programação que reflete a necessidade de um esforço extra no desenvolvimento que aparece quando implementa-se um código fácil e rápido ao invés da melhor solução conhecida.

Entre outras inúmeras tentativas de definições que encontramos por aí, todas levam ao mesmo raciocínio, é uma metáfora com um empréstimo financeiro, você precisa de algo fácil e rápido, hoje, você empresta mas amanhã terá que pagar e com certeza terá juros. Veja uma breve explicação do surgimento disso com as palavras de seu próprio idealizador.

Contextualizando, você está desenvolvendo um software e entregando suas funcionalidades gradualmente ao cliente conforme a demanda, seu cliente pede uma funcionalidade para ser entregue em três dias ou todo o restante do projeto será comprometido e você pode acabar perdendo-o, mas segundo sua estimativa de desenvolvedor [o correto] levaria uma semana. Porém, se você criar uma solução mais enxuta, deixar alguns “gaps” de segurança e performance passarem, minimizar ao máximo a complexidade de desenvolvimento (e por consequência maximizar a de manutenção) você consegue entregar em três dias. E então, você prefere falar para o seu cliente que não tem como entregar o que ele está pedindo em três dias e correr o risco de talvez até perder o projeto ou entregar a funcionalidade pendente de futuras melhorias e assumir o risco dos efeitos colaterais no futuro como problemas de performance, segurança, dificuldade de manutenção etc?

É uma escolha bem difícil, e foi devido a recorrência constante deste cenário nos projetos ágeis que se começou a discutir o conceito de débito técnico nas comunidades de princípios e práticas de desenvolvimento Ágil.

Voltando a discutir a resposta correta para a questão acima, a primeira opção não é uma escolha muito inteligente, entre outras consequências, dependendo do contexto, você poderá estar infringindo já o primeiro princípio do manifesto ágil. Então, podemos dizer que a segunda opção (e única restante) é a “menos pior”, digo isso pois a opção ideal é entregar a solução da melhor maneira, dentro do prazo e sem dependências posteriores, não é porque débito técnico está definido no agile alliance e é discutido (até um pouco defendido) por grandes nomes do desenvolvimento de software que ele seja uma boa prática e que devemos aplicar sempre que possível. Mas não sejamos utópicos, emergências existem, imprevistos também e temos que saber lidar com eles, às vezes a felicidade e a razão são alternativas diferentes na vida não é mesmo?

O que NÃO é

A Mess is not a Technical Debt.

Uncle Bob

Vale lembrar também que código mal escrito não é um débito técnico, ou seja, má decisões tomadas espontaneamente, código sem boas práticas mesmo com prazo disponível etc. Considere débito técnico, implementações simplistas por falta de prazo e não por falta de conhecimento ou habilidade técnica.

Algumas pessoas definem débito técnico como um preço que você paga por más decisões no seu código, não gosto dessa definição, pois ela deixa o termo muito vago e induz o desenvolvedor a entender qualquer “gambiarra” é um débito técnico, NÃO, débito técnico é aquilo que devidamente alinhado com o cliente foi desenvolvido de maneira mais simples/enxuta do que o correto devido interferências externas ou qualquer outro empecilho cujo a área de negócios não poderia esperar por tal desimpedimento.

Quer dizer que pode dar certo?

O alinhamento com o cliente é fundamental, o desenvolvedor poderá sugerir a criação de um débito técnico para uma entrega mais rápida, porém a decisão final deverá ser do cliente, afinal ele é quem sofrerá a consequência do prazo, uma hora ou outra, o tempo total estimado para desenvolver a funcionalidade deverá ser gasto, criando um débito técnico, esse tempo será apenas postergado. Se o cliente não está alinhado ou não está ciente do que é de fato um débito técnico, com certeza ele não irá entender quando a equipe de desenvolvimento pedir um prazo para trabalhar nos débitos técnicos, já que a maioria dos débitos técnicos não possuem valor de negócio palpável para ele.

Já parou para pensar sobre o acúmulo de débitos técnicos? Um projeto em que está com sérios problemas de prazo e o cliente nunca libera os desenvolvedores para resolverem os débitos técnicos pendentes, e a cada ciclo de desenvolvimento surgem novos débitos técnicos etc.

Se você conseguiu imaginar o cenário acima, muito provavelmente já passou por ele, infelizmente, esse cenário não é nenhuma novidade nos projetos ágeis atualmente, ainda existem muitos problemas que ainda não foram solucionados e muitas soluções que ainda não foram devidamente disseminadas no mercado, débito técnico é uma delas por exemplo, em muitos dos casos, ainda falta disciplina na sua utilização.

Qual a sua opinião?

Meu ponto de vista sobre débito técnico é, mesmo pesquisando bastante sobre o que é para escrever esse post, mesmo defendendo a utilização em alguns momentos, mesmo utilizando no meu dia a dia profissional, não sou a favor, acho que a sua utilização induz cada vez mais utilizá-lo e cada vez mais ser mais liberal quanto a critérios de definição, chegando ao ponto de considerar qualquer possível melhoria como débito técnico e inclusive a criação de débitos técnicos sem o alinhamento com o cliente, ou seja, de pouco em pouco, caminhamos para o cenário citado acima.

E você, já parou para refletir sua posição a respeito disso? Já sofreu com isso? Já utilizou? Já conseguiu utilizar com responsabilidade? Utilize os comentários, vamos debater !