O que são e “Dívidas Técnicas”? Por que aceitar? Por que pagar?

Neste post, apresento o conceito de “Dívida Técnica” (não é débito, é dívida). Explico por que nem sempre elas são ruins (aliás, são necessárias). Por fim, justifico o por que é importante pagar dívidas técnicas com argumentos que até seu gerente irá entender.

O que são Dívidas Técnicas?

Em minhas consultorias, sempre acabo abordando o conceito de dívida técnica. Eis uma das definições que mais me agrada:

Dívida Técnica é o gap entre a implementação atual de uma aplicação (também design e arquitetura) e aquela que seria necessária para que a aplicação continue entregando valor. Podemos medir a quantidade de dívida técnica pelo esforço para “fechar este gap”. – Michael Keeling

Por que aceitar?

Gosto da palavra “dívida” porque ela nos permite uma boa analogia:

Todos, eventualmente, contraímos dívidas. Para muitas pessoas (eu, inclusive), esta é uma das alternativas viáveis para que possamos fazer grandes aquisições (Exemplo: casa, carro, etc). Poderíamos, claro, guardar dinheiro e comprar sem dívidas – mas, isso tomaria tempo e as vezes não estamos dispostos a esperar.

Da mesma forma que ocorre na analogia, dívidas técnicas não são, necessariamente, ruins. Afinal, elas, muitas vezes, são a única alternativa disponível para que possamos lançar um software em menos tempo (da mesma forma que na analogia, fazer tudo certo é possível, mas custoso).

Outro ponto de reflexão, bem documentado no execelente livro Release It! (que recebeu, aliás, uma segunda edição [descobri agora]), em situações onde temos o sistema fica “fora do ar”, a prioridade é “levantar o sistema” e depois arrumar a bagunça necessária para isso. Essa bagunça é uma “dívida técnica”.

Por que pagar?

Voltemos a analogia:

O que vai acontecer se você comprar algo, contraindo uma dívida, e não a pagar? Fatos: você terá de pagar juros (quanto mais tempo demorar para pagar, mais cara será a dívida); se você não pagar, enfrentará restrições (ficando negativado); com o tempo, além das restrições, provavelmente perderá a posse do bem que gerou a dívida.

A mesma coisa ocorre com dívidas técnicas. Quanto mais tempo demorar para pagar, mais difícil será (mais caro, mesmo); Se não pagar a dívida, terá dificuldade em continuar mantendo o sistema gerando valor (mais difícil adicionar features, mais difícil manter o que está funcionando); Com o tempo, as restrições serão tão grandes que você não terá outra alternativa além de “jogar tudo fora” e começar do zero.

Concluindo

Dívidas técnicas não são necessariamente ruins. As vezes, elas são o meio para que você consiga cumprir prazos ou, até mesmo, resolver um incidente crítico. Entretanto, sempre que você contraí uma dívida técnica precisa pensar em um plano para pagar! Se não o fizer, com o tempo, seu trabalho irá parar de entregar valor e você terá a necessidade de começar tudo outra vez.

Muitos desenvolvedores alegam que não é escolha deles e sim do negócio contrair dívidas. Isso, provavelmente, é verdade na maioria dos casos. Afinal, a dívida boa é aquela que aceitamos para entregar valor em menos tempo. Cabe, entretanto, aos desenvolvedores, sinalizar a existência da dívida e garantir que exista orçamento para que esta seja paga antes que seja tarde demais.

PS: Release It! é um dos melhores livros que já tive a oportunidade de ler. É um dos preferidos do Ayende e um dos que mais me influenciou nos últimos anos. Leitura mais do que recomendada.

Capa: unsplash-logoRuth Enyedi

Compartilhe este insight:

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Elemar Júnior

Sou fundador e CEO da EximiaCo e atuo como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mais insights para o seu negócio

Veja mais alguns estudos e reflexões que podem gerar alguns insights para o seu negócio:

Em contextos extremos, é bom lembrar que é importante dedicarmos esforço para aquilo que, de alguma forma, influenciamos. Se um...
Neste post, compartilho mais algumas ideias que tenho adotado, com êxito, em meus projetos envolvendo Microsserviços e que podem ajudar...
In the previous post, I shared an example of how containers could help us to make the code clearer about...
Há tempos que percebo em mim a ocorrência de um padrão recorrente. Não acho que ele seja exclusividade minha, mas,...
In the previous post, I mentioned Mario Fusco who wrote a blog post series questioning the way Java developers are...
Se há algo que nunca vi foi consenso para o significado de “produto pronto” nas as áreas de desenvolvimento, marketing...
× Precisa de ajuda?