Desde quando o desenvolvimento de software se tornou uma atividade profissional milhares de pessoas têm tentado medir a produtividade dos seus programadores. E a primeira “métrica” que se imaginou, e talvez a mais famosa, é o loc ou lines of code.
A idéia é bem simples: basta contar quantas novas linhas de código o programador escreveu em cada dia, colocar tudo em uma planilha, e verificar se ele está rendendo mais ou menos.
Claro que hoje é fácil de perceber que não pode haver uma idéia mais absurda do que essa para se medir o trabalho de um programador. Acho que a estória que melhor ilustra essa incoerência foi o que aconteceu com um programador que participava do desenvolvimento do sistema operacional do Lisa, da Apple, em 1982.
Naquela época, os gerentes do projeto decidiram que cada desenvolvedor iria anotar semanalmente quantas linhas de código eles tinham produzido. Um desses desenvolvedores, Bill Atkinson, estava trabalhando na otimização de uma parte de código e acabou reescrevendo toda aquela seção de uma maneira mais genérica e que ainda por cima rodava seis vezes mais rápido. Como conseqüência, esse novo trecho acabou sendo bem mais conciso e acabou economizando 2000 linhas de código.
Quando teve que preencher o relatório de quantas linhas de código tinham sido produzidas, Bill anotou -2000 linhas. Isso mesmo, ele anotou um número negativo, o que deve ter criado uma grande inconsistência nos resultados de acompanhamento do projeto. Algumas semanas depois os gerentes pararam de cobrar a quantidade de linhas de código dos desenvolvedores.
Como desenvolvedor, acredito que qualquer tentativa de medir o progresso através de informações de baixo nível, como o código fonte, não mostra absolutamente nada de conclusivo. Mesmo existindo várias outras métricas mais aprimoradas que derivaram da loc mesmo assim são indicadores de quase nada. Mas o que fazer se, como disse Lord Kelvin, “o que não pode ser medido não existe”?
Eu só vejo uma solução: se você quer medir o progresso do desenvolvimento de um sistema então precisa medir funcionalidades macro. Por exemplo, medir quantos casos de uso foram implementados ou quantas funcionalidades de alto nível estão prontas para serem usadas. Tentar medir em níveis mais baixos que isso pode até gerar planilhas recheadas de números, mas que irão dizer absolutamente nada.
