Geralmente, é uma má idéia chamar seu chefe de idiota; portanto, minhas sugestões começam com a compreensão e discussão de métricas, em vez de rejeitá-las.
Algumas pessoas que não são realmente consideradas idiotas usaram métricas baseadas em linhas de código. Fred Brooks, Barry Boehm, Alcaparras Jones, Watts Humphries, Michael Fagan e Steve McConnell todos os usaram. Você provavelmente os usou mesmo que apenas para dizer a um colega, este módulo de Deus é de 4000 linhas, ele precisa ser dividido em classes menores.
Existem dados específicos relacionados a esta questão de uma fonte que muitos de nós respeitam.
http://www.codinghorror.com/blog/2006/07/diseconomies-of-scale-and-lines-of-code.html
http://www.codinghorror.com/blog/2005/08/are-all-programming-languages-the-same.html
http://discuss.joelonsoftware.com/default.asp?joel.3.286106.22
Eu suspeito que o melhor uso da linha de código por hora do programador é mostrar que, ao longo da vida do projeto, esse valor começará bastante alto, mas à medida que os defeitos são encontrados e corrigidos, novas linhas de código serão adicionadas para resolver problemas que não fizeram parte das estimativas originais e as linhas de código removidas para eliminar duplicação e melhorar a eficiência mostrarão que LOC / hr indica outras coisas além da produtividade.
- Quando o código é escrito rápido, desleixado, inchado e sem nenhuma tentativa de refatoração, a eficiência aparente será máxima. A moral aqui será que você deve tomar cuidado com o que mede.
- Para um desenvolvedor em particular, se estiver adicionando ou tocando em uma grande quantidade de código nesta semana, na próxima semana poderá haver uma dívida técnica a ser paga em termos de revisão, teste, depuração e retrabalho do código.
- Alguns desenvolvedores trabalharão a uma taxa de saída mais consistente do que outros. Pode-se constatar que eles gastam mais tempo obtendo boas histórias de usuários, revertendo-se muito rapidamente e fazendo testes de unidade correspondentes e, em seguida, reviram e rapidamente criam código focado apenas nas histórias de usuários. A conclusão aqui é que os desenvolvedores metódicos provavelmente terão uma mudança rápida, escreverão um código compacto e terão um baixo retrabalho porque entenderão muito bem o problema e a solução antes de começarem a codificar. Parece razoável que eles codifiquem menos porque codificam somente depois de refletir, em vez de antes e depois.
- Quando o código é avaliado quanto à sua densidade de defeitos, ele se mostra menos do que uniforme. Algum código será responsável pela maioria dos problemas e defeitos. Será um candidato para reescrever. Quando isso acontece, ele se tornará o código mais caro, devido ao alto grau de retrabalho. Ele terá as maiores linhas brutas de contagem de códigos (adicionadas, excluídas, modificadas, como pode ser relatado por uma ferramenta como CVS ou SVN), mas as menores linhas líquidas de código por hora investidas. Isso pode acabar sendo uma combinação do código, implementando o problema mais complexo ou a solução mais complicada.
Independentemente do resultado do debate sobre a produtividade do programador em linhas de código, você descobrirá que precisa de mais mão-de-obra do que pode e o sistema nunca será concluído a tempo. Suas ferramentas reais não são métricas. São o uso de metodologia superior, os melhores desenvolvedores que você pode contratar ou treinar e o controle de escopo e risco (provavelmente com métodos Agile).