Dívidas técnicas de naturezas similares podem ter impactos muito diferentes na produtividade dos times de desenvolvimento. Por isso, iniciativas ingênuas para “pagar” a maior quantidade de dívidas técnicas, sem critério claro de priorização, embora bem intencionadas, acabam não produzindo, muitas vezes, resultados perceptíveis na redução da complexidade.

[tweet]As dívidas técnicas e a complexidade tem muito mais impacto nas partes do código que são alteradas com maior frequência.[/tweet] Trechos de código, mesmo mal escritos,  que não sofrem alterações frequentes ao longo do tempo estão “estáveis”. Refactoring nesses trechos de código acabam tendo pouco impacto para a redução dos custos e dos prazos. Além disso, aumentam consideravelmente as chances de novos bugs.

No gráfico acima, podemos ver que há clara concentração de commits em uma parcela muito pequena de arquivos no projeto do servidor do RavenDB, por exemplo. Um arquivo, apenas, recebeu 3% de todos os commits. Mais de 50% dos commits envolveu menos de 10% de toda a base de código. Parece evidente que as dívidas técnicas presentes nesses arquivos acabariam tendo impactos muito mais altos para a produtividade do time. Também parece lógico que o código desses arquivos fosse aquele com maior cobertura por testes automatizados.

A distribuição de commits encontrada na base de código do servidor do RavenDB é comum a quase comum a quase todas as bases de código, segundo Adam Tornhill (que tem influenciado muitas das nossas ideias sobre como tratar dívidas técnicas). Logo, os mesmos insights são aplicáveis a quase todos os projetos.

[tweet]Os “juros” das dívidas técnicas e da complexidade ficam ainda mais evidentes nas partes do código mantidas por muitas pessoas.[/tweet] Afinal, código ruim, alterado frequentemente por muita gente fica ainda mais difícil de entender e, consequentemente, impacta muito a produtividade.

Mais uma vez, é fácil verificar que poucos arquivos são alterados por muitas pessoas. Geralmente, inclusive, há uma correlação de proporcionalidade entre número de commits que um arquivo recebe e o número de programadores trabalhando nesse arquivo.

Dívidas técnicas são ruins. Porém, algumas são piores do que outras. Nesses tempos em que temos prazos cada vez mais curtos e pressão cada vez maior para entregar mais features, temos que ser inteligentes na seleção de que trabalho gera mais resultado.