O projeto começa e a equipe de desenvolvimento está produzindo muito, várias partes do software vão sendo construídas e o time está feliz.
Passadas algumas semanas a produtividade caiu um pouco, a euforia do time passou, mas o projeto ainda transcorre dentro da normalidade e o time de desenvolvimento não está aborrecido.
Passadas mais algumas semanas e a produtividade cai drasticamente, muito bugs começam a ser encontrados, neste momento o time já está com a moral baixa, o cliente notou que o projeto não anda bem, o custo de mudança de qualquer funcionalidade é muito alto, e você não entende o motivo desta queda de produtividade, afinal de contas o time é bom, a especificação foi bem feita, o cliente está próximo, a comunicação flui e as pessoas são comprometidas. Então o que está acontecendo?
É bem provável que o projeto possua uma dívida técnica grande.
O termo dívida técnica é utilizado para indicar trechos de código que foram mal escritos, ou escritos de qualquer forma, sem respeitar padrões, são as chamadas gambiarras. Com o passar do tempo estes trechos de código vão atrapalhar os desenvolvedores, e mudanças que teoricamente seriam simples passam a levar muito tempo para serem realizadas.
É natural que o custo de mudança do software aumente com o passar do tempo, pois logicamente quanto mais código um projeto possui maior tende a ser o impacto de adicionar uma funcionalidade (mais código). Se formos alterar uma funcionalidade o custo de mudança tende ser maior ainda, já que em alguns casos uma mudança de regra de negócio pode afetar várias partes do software.
É provável que você já tenha se deparado com uma funcionalidade impossível de ser evoluída, tamanho era a falta de qualidade do código, em alguns casos quando isto ocorre somos obrigados a refazer toda a funcionalidade, pois o código se tornou ilegível, e isto gera um grande desperdício de tempo e dinheiro.
Muitos desenvolvedores ainda consideram que qualidade do código é algo extra, que se der para produzir código de qualidade legal, mas o foco é entregar software com qualidade, não necessariamente produzindo código de qualidade. Esta é um escolha perigosa, pois a menos que o projeto seja bem pequeno o desenvolvedor vai precisar pagar a conta da dívida técnica produzida, ou simplesmente o projeto vai parar.
Mas como desenvolver software sem gerar dívida técnica? Ah meu amigo, isto é assunto para outro post 😉 mas recomendo assistir um vídeo do Alexandre Freire da Industrial Logic, que falou sobre isto no Agile Brazil 2012 -> Link do vídeo na InfoQ.
