Existem diferentes tipos de dívida de software. A dívida técnica é a mais conhecida, mas não a única. Existem também as dívidas de competência e de qualidade. As dívidas de software podem causar o aumento dos custos de manutenção e também desencorajar desenvolvedores. Felizmente existem soluções para gerenciá-las.
No post "O outro tipo de dívida de software", Niklas Björnerstedt fala sobre a "dívida de competência". Sua definição é a seguinte:
A diferença entre o que existe no seu código e o quanto dele você entende.
Para manter a manutenção de software baixa, deve-se atentar tanto à dívida técnica quanto à dívida de competência, conforme explica Niklas:
Assim como a dívida técnica, que cresce inevitavelmente com o tempo caso não seja enfrentado, a dívida de competência também segue a mesma regra. A maior diferença entre elas é que, enquanto a dívida técnica cresce conforme o código sofre alterações, a dívida de competência cresce mais rápido se o código não for alterado! A dívidade competência é, portanto, um problema que é mais agudo em sistemas maduros, que não estão mais em desenvolvimento ativo.
Niklas propõe duas técnicas clássicas que podem ser usadas para reduzir essa dívida: programação em pares e refatoração de código:
Para mim, o valor real da programação em pares é a redução das dívidas técnica e de competência. Ao trabalhar em pares, as equipes ampliam as áreas da base de código com as quais estão familirializadas e aumentam a troca de experiências. De maneira similar, o valor da refatoração não é apenas a redução da dívida técnica. A refatoração é uma ótima maneira de reduzir também a dívida de competência. Só se pode alterar um sistema se ele realmente for bem compreendido.
Quando a dívida de competência se acumula, o esforço necessário para manter sistemas aumenta, até chegar ao ponto em que as empresas começam a considerar a substituição do sistema:
Pode-se alegar que um determinado sistema antigo é difícil de manter, quando na verdade o problema é que não se entende corretamente como o sistema funcionava. Sim, a dívida técnica torna as coisas ainda piores, uma vez que código confuso e a falta de testes automatizados tornam frustrante a tentativa de entender o sistema. O impulso por reescrever vem normalmente quando apenas poucos dos desenvolvedores originais ainda restam na equipe e a empresa não consegue encontrar novos desenvolvedores dispostos a aprender.
Mike Hustler escreveu um post sobre a forma mais ágil de gerenciar a dívida técnica, no qual discute como equlibrar entre desenvolver novas funcionalidades em um produto e gerenciar a dívida técnica. Ele explica como a abordagem de transferir produtos para times de manutenção pode levar ao crescimento das dívidas técnicas e de competência:
Já vi organizações criando times de manutenção separados, os quais tinham metade do tamanho de um time que desenvolve novas funcionalidades. Em minha opinião, essa é uma abordagem errônea (pelo menos comparado ao tamanho dos times que trabalhamos). (...) O comprometimento que surge de se sentir orgulho por ser dono de um produto é perdido quando alguém fica responsável por solucionar os bugs criados por uma outra pessoa que, na verdade, pertence a um outro time.
Sem uma comunicação sólida, as razões que levam a optar por uma determinada abordagem ou solução são perdidas. O conhecimento do domínio não se torna presente, e a eficiência em corrigir problemas é reduzida. Ainda pior, já vi times de manutenção com menos experiência que tiveram dificuldades para identificar a causa raiz de problemas, resultando em remendos onde um redesenho seria mais apropriado.
A dívida técnica deprime os desenvolvedores e pode levá-los a deixar o time, o que aumenta ainda mais a dívida de competência, conforme Cory House descreve em seu post "Sete razões porque código limpo é importante":
Escrever código confuso e de maneira desleixada injeta dívida técnica em nossos projetos. Enquanto dívida técnica pode ser útil quando considerada cuidadosamente no seu contexto, a dívida técnica excessiva é deprimente e afasta talentos das organizações. Quando coisas simples se tornam complexas, desenvolvedores ficam insatisfeitos e vão trabalhar em outro lugar. Desenvolvedores obtêm mais satisfação a partir da qualidade do seu trabalho do que da quantidade. A dívida técnica diminui as chances de reuso e estabelece um nível baixo de qualidade para toda a base de código.
David Hammerslag escreveu o post "Quer previsibilidade? Evite a dívida de qualidade" onde ele discute os efeitos de encontrar defeitos no código e não corrigi-los. A definição de David para o a dívida de qualidade é a seguinte:
A dívida de qualidade é uma medida do esforço necessária para corrigir os defeitos existentes em um software a qualquer momento.
David faz uma comparação entre a dívida de qualidade e a dívida técnica:
A dívida técnica é uma medida da qualidade do design e do código, os quais são a qualidade interna do software. A dívida de qualidade é uma medida da qualidade externa do código: as coisas que o usuário vê e experimenta. Um usuário nunca enxerga (diretamente) a dívida técnica.
Um programa pode ser completamente livre de dívida de qualidade mas, em contrapartida, pode possuir uma enorme dívida técnica. Esse mesmo programa pode implementar corretamente todas as funcionalidades requeridas e executar sem nenhuma falha. Ainda assim sua dívida técnica pode ser enorme, contendo todas as más práticas de design e implementação que se possa imaginar. De maneira inversa, o código mais bem projetado e elegante pode produzir resultados errados ou não conter todas as funcionalidades esperadas.
A dívida de qualidade não deve ser ignorada, conforme David explica:
A dívida de qualidade é como uma dívida financeira: quanto mais tempo se demora com ela, mais difícil torna-se para liquidá-la. No pior caso, um projeto adia os testes até que o desenvolvimento esteja completo. É fato que, quanto mais tempo um defeito permanece no código, mais difícil será corrigi-lo. Se vários defeitos persistem (sejam eles conhecidos ou não), o efeito é agravado ainda mais, pois esses defeitos tendem a mascarar uns aos outros.
David sugere diversas práticas ágeis que podem ser usadas para gerenciar defeitos e manter baixa a dívida de qualidade:
- Definição de pronto (Done)
- BDD e testes de aceitação automatizados
- Integração contínua
- Testes automatizados
- Não tolerar "janelas quebradas" (tolerância zero).