Concrete Logo
Hamburger button

Débito Técnico

  • Blog
  • 18 de Junho de 2012
Share

 

Esta semana, na lista de Trainers da Scrum.org tivemos uma boa discussão sobre Débito Técnico, o que me levou a escrever este texto com parte do conteúdo discutido.

Curiosamente para muitas pessoas o Débito Técnico ainda é algo misterioso e de difícil compreensão. Esse diagnóstico é comprovado ao observarmos a forma como o Débito Técnico é endereçado ou ignorado.

A analogia básica para o termo Débito Técnico é com uma dívida. Dívidas, de forma ululante, têm juros. Como as dívidas têm juros, elas não crescem linearmente, os juros se acumulam em cima de juros não pagos. O crescimento de uma dívida é dessa forma exponencial.

Chamar o Débito Técnico com este nome, tem então como objetivo mostrar como a eliminação de Débito Técnico é importante, que o débito técnico se acumula e pode te prejudicar rapidamente pela caracteristica exponencial de crescimento.
 

Gênesis

 

A seguir coloco com autorização do autor a tradução do post  de Julho de 2010 do blog do Steve Freeman com outra analogia muito boa sobre débito técnico. Mesmo se você já conhece ou leu o original, vale rever o texto abaixo:

    “Código ruim não é uma Dívida Técnica, é uma opção de compra sem hedge”

     

    Isso foi uma ideia do Chris Matts. Ele percebeu que o problema com a metáfora “Débito Técnico” é que para gerentes, débito pode ser uma coisa boa. Executivos podem precisar tomar mais dívida para fazer as finanças funcionarem melhor, podem até ter incentivos ao pagar menos impostos por causa disso. E isso não é o mesmo que uma dívida no seu cartão de crédito pessoal. Chris criou uma metáfora melhor chamada, Opção de Compra.

    Eu “escrevo” uma Opção de Compra quando vendo para alguém o direito, mas não a obrigação, de comprar no futuro uma quantidade de algo a um preço fixado hoje. Então, por um pagamento agora, eu concordo em vender para você 10,000 Papais Noel de chocolate por 56 centavos cada, a qualquer tempo até 10 de Dezembro. Você está preparado para pagar um valor prêmio porque quer ter certeza que terá os Noéis nas suas lojas no Natal a um preço que você conseguirá vender.

    Do meu lado, se o preço dos Noéis permacerem baixos, fico com o seu pagamento e tenho um lucro. Mas, também corro o risco de ter que providenciar os chocolates de Natal se o preço explodir para 72 centavos. Eu posso me proteger disso, combinando com outra pessoa de comprar por 56 centavos ou menos, ou por efetivamente ter este produto em estoque. Ou, eu posso simplesmente arriscar receber o prêmio. Isso é chamado de Opção sem Hedge (sem cobertura) ou Opção “Nua”. No mundo financeiro, isso é muito arriscado porque não há limites inferior para as perdas. Tem que fornecer o produto da opção, os Noéis, em qualquer preço que eles custarem quando as opções forem exercidas.

    Opções de Compra são um modelo melhor que Débito para código ruim (sem testes) porque captura a imprevisibilidade do que fazemos. Se eu jogar uma feature sem limpar o código sou beneficiado imediatamente, recebo o prêmio. Se nunca mais olhar para esse código, estou no lucro e, em retrospectiva, teria sido tolo gastar tempo limpando o código.

    Por outro lado, se uma nova e radical funcionalidade aparece para que eu faça, tratar todos aqueles ajustes apressados , repentinamente se torna extremamente caro. Exemplos que já vi são de um novo cliente grande que quer portar a aplicação para uma plataforma diferente, ou um novo requisito regulatório que precisa de um novo relatório. Problemas equivalentes aparecem se há um erro e tenho que interpretar e corrigir esse erro próximo de um prazo de entrega. Ou se os membros do time mudam e não tem ninguém com conhecimento tácito para ajudar a entender o código. O mercado se moveu e foi para longe de onde pensava que estaríamos, e a minha opção foi exercida.

    Mesmo sendo mais caro fazer as coisas de forma limpa (e não estou convencido disso em um horizonte maior que 2 semanas), também será menos arriscado. Um sistema confuso é cheio de opções de compra sem Hedge, desprotegidas  e cada uma pode ter um custo imprevisivel se em algum momento forem exercidas. Todos nós vimos o que isso pode fazer para mercados financeiros e o medo inerente dessa falha, que quando vem, é repentina — tudo está bem até que não está. Já vi alguns sistemas que são simplesmente difíceis demais de mudar no ritmo da competição e os donos estão em sérios apuros.

    Então isso transforma refatorar em comprar uma opção também (hedge). Eu pago um prêmio agora para ter mais opções de para onde levar o código mais tarde. Esta é uma atividade mundana e óbvia em muitos aspectos de negócios – apesar de aparentemente não ser assim em desenvolvimento de software. Não preciso gastar esse dinheiro se sei exatamente o que vai acontecer, se tenho conhecimento perfeito de partes relevantes do futuro. Só não consigo me lembrar de quando uma situação assim já aconteceu.

    Então, da próxima vez que você tiver que lidar com prazos de entrega não razoáveis, não fale de Débito Técnico. Débito é algo previsível e pode ser gerenciado, é apenas mais uma ferramenta. Tente falar de Opção de Compra sem Hedge. Agora, tudo o que precisamos é uma forma de precificar Código Fétido.

    Steve Freeman

 
Continuando:

A analogia certamente chama a atenção para um aspecto importante do Débito Técnico, a falta de limites das perdas que podemos ter.

Mas qual é a natureza específica do Débito Técnico ?

Mary Poppendieck caracteriza o Débito Técnico como uma séria forma de desperdício, como pode ser visto no PDF da sua apresentação feita em Outubro de 2011 no European Lean IT Summit. O vídeo tem menos de 17 minutos e está no YouTube com título Mary Poppendieck at the European Lean IT Summit.

 
Débito técnico tem várias características: código mal escrito, falta de testes e dependências.

Muitas vezes ainda caracterizamos e fazemos distinção entre o código ruim que o Time sabe que deixou, e aquele que traz problemas sem que o time saiba que fez. O artigo Technical Debt Quadrant do Martin Fowler em seu blog, fala sobre essa questão e um pouco mais sobre a natureza do  débito técnico. Na sua visão, e concordo com ele, o Débito Técnico é inevitável naturalmente. Disso é fácil concluir que devemos evitá-lo ao máximo e assim conviver apenas com o que não conseguirmos manter fora do código.
 

E quais são os efeitos nocivos desse código de dificil manutenção?

Está claro, o aumento do custo total da sua propriedade do código (TCO). Manter e evoluir sua base se torna cada vez mais caro. E pior, mesmo com recursos virtualmente infinitos, podemos chegar no caso tipico em que não é possível evoluir o código em uma velocidade competitiva.

Você terá um tempo de vida menor da sua base, maior tempo para novos releases (time to market) e custos crescentes.

Dependendo do ambiente de negócios e da sua competição, pode ser a diferença em TER uma empresa daqui a 5 anos ou não.
 

E o que podemos fazer conscientemente para melhorar?

O assunto é amplamente endereçado, por exemplo, no livro Managing Software Debt: Building for Inevitable Change do Chris Sterling e vai muito além das práticas usuais de Engenharia de Software recomendadas. O que nos leva a concluir que as práticas que todos os autores recomendam, são realmente o mínimo que podemos fazer para considerar um código pronto para ir para produção.

 

Se o seu Time utiliza uma definição de pronto (DoD), cobertura de testes, revisão de código por pares (ou pair programming), refatoração de código e de design, eliminação de dependências, etc., considere como sendo todos fatores indispensáveis. Não abra mão deles para não se enfiar em um buraco que pode não ter fundo.