O artigo fala sobre algumas falsas crenças da “indústria” do software: linguagens restritivas, economia na forma de contratação de desenvolvedores medíocres e tentativa de encurtamento de prazos de entrega através da adição de mais pessoas aos projetos, entre outras.

Boa leitura!

Produtividade do desenvolvedor: Média vs. Mediana

Ok, primeiro um pouco de matemática: média é definida como o valor matemático médio de uma série de números. Para o conjunto de números acima, a média é igual a 4,55. A mediana é definida como o número intermediário de uma série numérica ordenada, que, no exemplo acima, vale 5,5.

Porque estou falado sobre isso? Bem, tem a ver com habilidades de desenvolvedor. Veja bem, desenvolvedores muito bons são muito mais produtivos do que os médios (isto foi documentado em vários lugares, incluindo o Mythical Man Mouth e Joel). De fato, algumas estatísticas dizem que desenvolvedores realmente bons são ordens de magnitude melhores do que os ruins.

Considere esta versão do gráfico:

Neste caso, a média é 2,7 e a mediana é 2. Se a altura da linha do gráfico representa a produtividade do programador, este segundo gráfico é mais próximo da realidade.

Então o que isso significa para o desenvolvimento? Gerentes costumavam pensar que esse era um simples ângilo de 45 graus e que, mesmo que você não consiga os melhores e mais brilhantes, você ainda conseguiria utilidade em desenvolvedores medíocres. Mas construir software não é como cavar uma vala. Mesmo maus cavadores podem fazer um buraco. Em software, o que você (e outros) escreve hoje, torna-se a fundação para o que vem amanhã. Se você tem desenvolvedores ruins construindo a fundação, os desenvolvedores muito bons tem que voltar e consertá-la antes de construir mais coisas úteis. Contratar desenvolvedores medíocres (ou apenas médios) diminui a velocidade do projeto. Junte isso ao fato de que adicionar pessoas à projetos atrasados os atrasa mais ainda e você entenderá porque a maior parte do desenvolvimento corporativo é feito num ritmo glacial. Construir software complexo com muitos programadores médios destaca duas métricas de projeto negativas: a tentativa de escalar adicionando pessoas e a de que desenvolvedores médios produzem código na escala média. Mas a verdade se parece mais com o segundo gráfico: a produtividade geral é trazida ao nível da mediana, não da média.

Toda uma indústria foi criada para resolver esse problema. Pensou-se que você poderia resolvê-lo de duas maneiras. Primeiro, construir linguagens restritivas que mantém os maus desenvolvedores fora de problemas. Mas, Glenn Vanderburg tem uma frase extremamente precisa que reflete a realidade que ele (e eu) viu em projetos: Maus desenvolvedores moverão o céu e a terra para fazer a coisa errada. Linguagens de computador de comando e controle não são como as leis e seu carro, te forçando a dirigir em velocidades mais baixas e com mais segurança. Ao final do dia, linguagens fracas diminuem a velocidade de seus melhores desenvolvedores e não impedem os ruins e medíocres de escrever código horrível.

A outra tentativa de consertar isso foi pegar essas linguagens restritivas e construir ferramentas realmente inteligentes para ajudar os desenvolvedores a gerar código mais rapidamente. Esta é o clássico apelo de vendas do Visual Basic: ninguém pode se machucar, e você pode contratar desenvolvedores mais baratos para escrever seu código, sem ter que pagar um bom salário àqueles chatos artesãos de software. É fato bem conhecido que a Microsoft, internamente, chama desenvolvedores medíocres de “Morts” e tem neles o público-alvo de algumas ferramentas. É claro, isso não se aplica a todos os desenvolvedores Visual Basic e também não aos bons desenvolvedores na plataforma .NET. Mas é realidade que esta estratégia ambígua é como os vendedores venderam ferramentas nas últimas décadas.

E agora vemos que isto não funciona. Parte da ascensão das linguagens dinâmicas deve-se à percepção de que linguagens de comando e controle não torna o código de desenvolvedores médios melhor e ainda atrapalha os desenvolvedores realmente bons. Porque não encontrar uma forma de libertar os bons desenvolvedores e deixá-los caminhar tão rápido quanto podem? Ruby on Rails é um bom exemplo do uso de DSLs para criar uma linguagem mais simples em cima do Ruby para coisas como relacionamentos do ActiveRecord. Para código do dia-a-dia, você pode ficar na camada alta, de abstração simples. Se você realmente precisar, pode mergulhar abaixo desse nível de abstração e ter trabalho real feito em Ruby. Para a maioria dos projetos Ruby em que trabalhei, o uso de classes abertas é feito estratégicamente, respondendo por aproximadamente 1,5% e 4% do total de linhas de código. Ainda assim, esse uso cirúrgico de um dos tipos de metaprogramação disponível em Ruby, permite eliminar centenas de linhas de código.

E o que tudo isso significa? Primeiro, dê aos bons desenvolvedores ferramentas poderosas e você terá software de alta qualidade mais rápido. Segundo, como indústria, nos tornariamos mais produtivos se 30% dos desenvolvedores existentes fossem despedidos amanhã. Ter mais corpos não ajuda projetos e ter que tomar conta de desenvolvedores ruins acaba com a produtividade dos seus bons desenvolvedores. Software é muito complexo para se tornar um processo de manufaturação em linha de montagem, pelo menos por enquanto. Bons desenvolvedores de software ainda são os artesãos, não importa o quanto isso incomoda as empresas que desejam que isso fosse verdade.