Um desafio para programadores e escritores

Photo by Pixabay from Pexels

Todo mundo gosta de desafios de vez em quando. E pra quem gosta de escrever, o evento conhecido como NaNoWriMo (National Novel Writing Month, ou Mês Nacional da Escrita de Livros, em uma tradução livre) talvez seja um dos maiores e mais empolgantes. Apesar de originalmente ser uma proposta “nacional” (nos EUA), o evento hoje tem proporções internacionais e acontece todos os anos em novembro. O objetivo é bem direto: escrever 50.000 palavras em 1 mês. A ideia é que essas palavras sejam parte de um livro ou mesmo histórias completas.

Mas afinal, o que isso tem a ver com programação? A princípio, nada. Contudo, após anos vendo pessoas falarem do NaNoWriMo, me veio a mente a ideia de fazer um paralelo entre esse desafio e a produtividade de um programador comum: será que escrevemos 50 mil palavras (de código) em 1 mês? Ou então 50 mil linhas? E será que faz algum sentido medir a produtividade de um programador pelo número de linhas que produz?

Para responder essas perguntas, como sempre, comecei pelo óbvio: procurando referências. Não demorei para encontrar uma citação de Fred Brooks, diretamente do clássico The Mythical Man Month (do qual falei aqui). Em um dos capítulos do livro o autor descreve a taxa de produtividade alcançada por seus colegas durante o desenvolvimento do OS/360, sistema operacional da IBM desenvolvido e lançado nos anos 60:

Produtividade na faixa das 600-800 instruções depuradas por homem/ano foram observadas em grupos de controle. Taxas de produtividade de 2000-3000 instruções depuradas foram atingidas pelo grupo de conversores de linguagem [do OS/360].

Se dividirmos a produtividade alcançada pelo time de Brooks pelo número de dias úteis em um ano, encontraremos algo em torno de 10 linhas de código por dia. Achou pouco? Vamos considerar então algumas estatísticas mais recentes: um estudo de 2011 publicado no livro The Economics of Software Quality afirma que uma equipe que trabalhou em um sistema para controle de centrais telefônicas escrito em C++ apresentou produtividade de 281 linhas/mês, ou seja, algo em torno de 14 linhas por dia.

Sendo assim, se fôssemos criar um hipotético “NaNoWriMo para programadores”, no qual o objetivo seria que cada programador escrevesse 50 mil linhas de código, o prazo de 1 mês não seria suficiente: se considerarmos uma taxa de produtividade de 281 linhas/mês, atingir o objetivo do desafio levaria pouco mais de 177 meses, ou 14 anos.

Confesso que depois de olhar para esses dados fiquei surpreso e até mesmo um pouco indignado. Eu tenho certeza que escrevo bem mais do que 10 ou 15 linhas por dia. Sem dúvida, o número está mais para a casa das centenas ou milhares do que para dezenas, e acredito que o mesmo aconteça com a maioria de meus colegas de profissão. Decidi então fazer um rápido tira-teima: abri uma janela da linha de comando, acessei a pasta de um projeto que comecei no último mês e rodei o seguinte comando:

git log --author="Gabriel Ullmann" --shortstat

O comando acima mostra todos os commits feitos por mim em um repositório Git, bem como o número de linhas incluídas e excluídas. Pela minha contagem, em pouco mais de 1 mês incluí 4772 linhas em 34 commits, uma média de 143 linhas por commit. O que se pode concluir por esses indicadores é que minha produtividade foi 16 vezes maior que a do time descrito em The Economics of Software Quality, ou mais de 20 vezes maior que a dos programadores do IBM OS/360.

Será que tenho habilidades sobre-humanas de programação? Na verdade, acredito que só cheguei a esses indicadores de produtividade absurdos porque a minha análise foi bem rasa. Não se pode julgar o volume de trabalho ou a competência de um programador apenas pelo número de linhas de código que ele escreve, e acredito que o principal motivo seja o famoso “boilerplate”.

Sabe aquela linha nao seu script ou classe na qual tem só um “abre-chaves”? Ou um “public class qualquerCoisa”? Ou declarações de imports? Tudo isso é boilerplate. O dicionário Cambridge define o termo como:

Texto que pode ser copiado e utilizado em documentos legais ou programas de computador, exigindo apenas pequenas alterações.”

Ao longo de um grande projeto muito código se repete, e nem sempre isso é culpa do programador. Muitas vezes a repetição é inerente a forma como a linguagem é construída (por exemplo, no caso dos imports e classes em PHP, Java ou C). Esses trechos são tão repetitivos que muitas IDEs até mesmo te ajudam a escrevê-los através de ferramentas de auto-complete ou geração de código. Ou seja, boilerplate não é código que o programador que escrever para realizar alguma tarefa ou expressar lógica de negócio, e portanto não pode ser contado como código “produtivo”. Ele simplesmente tem que estar lá, é isso.

Embora eu não tenha tempo para realizar uma análise tão detalhada, acredito que se desconsiderássemos o boilerplate e alterações realizadas no código que não realmente envolveram alterar a lógica do programa (ex: mudar o texto em uma string) imagino que o número de linhas cairia para menos da metade. Se desconsiderássemos ainda o código que está duplicado ao longo do projeto e que poderia ser abstraído de alguma forma, o número cairia ainda mais. Afinal, no que refere a código, menos é mais. Deixemos a verbosidade para os escritores 🙂

Fontes: