Robert “Uncle Bob” Martin, desenvolvedor veterano com mais de 50 anos de experiência, abre um de seus livros analisando um problema que, segundo ele, assola a maior parte das organizações que desenvolvem software: o aumento exponencial do “custo por linha modificada”, ao longo do tempo, nas bases de código.
Robert Martin utiliza o número de linhas de código alteradas como um proxy para métrica de atividade e entrega de um time. É fato que essa métrica não é, de maneira alguma, precisa, mas geralmente é suficiente.
Em termos simples, Robert Martin argumenta que o crescimento dos times de desenvolvimento ou maior senioridade geralmente, em certo ponto, deixam de impactar o volume de entregas.
A razão, defendida por “Uncle Bob”, é que, com o tempo, menos atenção é dada para estrutura e arquitetura do software e a “limpeza” do código. Geralmente, a justificativa é a pressão por entregas de features para o negócio em prazos, no mínimo, desafiadores.
Do ponto de vista dos times técnicos, essa “perda de produtividade” colabora para a queda da motivação. Afinal, raramente significa que o time esteja trabalhando com menos empenho.
Do ponto de vista dos executivos de uma organização a questão não é, de forma alguma mais animadora. Na prática, mais dinheiro está sendo gasto para gerar menos benefícios e não costuma demorar muito tempo para que os impactos sejam sentidos na competitividade.
A provocação de Robert Martin é de que há uma falsa ideia instalada de que código “bagunçado” é mais rápido de escrever do que aquele que é bem escrito.
The only way to go faster, is to go well.
Robert “Uncle Bob” Martin
Não temos registros temporais relacionando o volume de investimento em equipes de TI e o volume de entregas. Entretanto, empiricamente, a constatação de Robert Martin parece assustadoramente correta.
Recomendamos fortemente que as organizações recuperem as informações relacionadas aos investimentos nos times de TI e com relação ao volume de linhas modificadas ao longo do tempo. Mais do que isso, que estabeleçam o “custo por linha modificada” como indicador a ser acompanhado. Este parece ser um indicador mais do que efetivo para constatar o “desgaste” das bases de código.
Esperança é uma péssima estratégia.
