Objectzilla

Andy Hunt já dizia que nós deveríamos aprender uma nova linguagem a cada ano. É claro que sempre tem uns merdas que citam Malcolm Gladwell (e sua teoria de que se leva 10 anos de prática pra que alguém desenvolva um grande talento (link, link)) para desqualificar a sugestão de Hunt, afirmando que um ano “é muito pouco”. Puro jogo de palavras! Pois não se espera de ninguém ser um fodão na linguagem em que se aventurou. É suficiente apenas um mínimo de entendimento nos princípios e na filosofia da nova linguagem, além da cultura dos principais evangelistas. Um ano é suficiente para ter, sei lá, um quinto de conhecimento que o guru-criador da linguagem tem.

Outros usam também a conhecida citação “programar é difícil” para demonstrar que aprender novas linguagens não vale a pena, já que é contra-senso encarar coisas difíceis todo ano. Discordo, uma coisa é aprender a programar, outra é aprender uma nova linguagem. Programar é um conceito abstrato: transformar uma idéia em solução computacional. Linguagem é concreto: a ferramenta utilizada para por a solução computacional em prática. Confundir programação com linguagem é típico de quem nunca aprendeu mais de uma linguagem.

Aprender uma nova linguagem é útil. Principalmente quando você sai de uma “visão de mundo”, que é apregoada pela comunidade da linguagem, e entra numa outra, completamente diferente. Isso é tão libertador quanto aqueles sortudos viajantes, que andam de país em país; onde, em cada uma, percebe como as pessoas são diferentes e que existe um mundo muito maior do que eles próprios supunham imaginar.

Tudo isso para sugerir duas linguagens da cauda longa: uma é Haskell, linguagem funcional que gera código nativo (com desempenho comparável a C), a outra é Erlang, linguagem também funcional com foco em concorrência e que roda em uma máquina virtual especial para sistemas que não podem cair.

Eu estou aprendendo Haskell e comecei pelo ótimo tutorial Learn You a Haskell for Great Good, escrito pelo esloveno Miran Lipovača. Já Erlang (que eu havia começado a aprender há dois anos atrás, mas parei no meio), pretendo comecar no ano que vem, e irei seguir um tutorial que ainda não li, mas é cria do anterior: Learn You Some Erlang for Great Good, escrito pelo franco-canadense Frederic Trottier-Hebert.

Se você já está de saco cheio da mediocriade dos usuários de Java, vale a tentativa.

Bom, já havia falado que havia lido o livro “The Mythical Man-Month”. Hoje vou falar sobre mais algumas coisas sobre o texto.

O autor defende que horas e pessoas não são intercambiáveis, ou seja, não dá para aumentar a equipe e esperar que o produto seja entregue mais rápido. Com mais pessoas, pode ser que seja mais rápido, pode ser que seja a mesma coisa, ou ainda pode ser mais lento que se mantivesse a equipe menor. E foi ainda mais enfático: adicionar pessoas num projeto atrasado, deixa-o mais atrasado.

A razão para esse fenômeno, para muitos ainda contraintuituvo, é que determinadas tarefas são difíceis de serem feitas em paralelo, e quanto mais pessoas, maior o tempo gasto em comunicação entre os membros, em detrimento do trabalho “útil”.

Uma outra coisa que o livro fala é que a diferença de produtividade entre um excelente programador e um mau programador é de 10 para 1. O que significa que nem sempre compensa contratar os piores programadores porque não compensa pelo custo-benefício.

Mas chega a desanimar se comparar o livro com a realidade brasileira. Não se fala na área man-month, man-day, homens-mês ou homens-dia; fala-se simplesmente hora (do tipo: “essa alteração leva tantas horas”), como se a pessoa encarregada em construir o programa simplemente ficasse fora da equação, e o projeto ficasse pronto pela simples passagem do tempo.

Pra piorar: o valor percebido de um software está em quanto satisfez as expectativas do cliente, não em quantas horas foram gastas na construção. Entre uma feature que traz grande satisfação, mas poucas horas, e outra que traz pouca satisfação, mas muitas horas; a última seria economicamente vantajosa pra quem vende horas. (Percebe porque está cheio de consultoria pereba?)

E a razão 10:1 para a produtividade entre o melhor e o pior pode até indicar pra uma empresa de software que vale a pena contratar o melhor. Mas como são raras as empresas sensíveis a esse ponto, essa razão significa simplesmente uma coisa: quem faz muito ganha relativamente pouco e quem faz pouco ganha relativamente muito. Implica que não é vantagem para nenhum programador melhorar seu próprio nível educacional, pois uma eventual reciclarem teria pouco reconhecimento.

E isso é verdade! Acredito que tenha muitos profissionais que não sabem como é um bom projeto de software, seja porque nunca trabalhou num, seja porque nunca se qualificou para tal.

Dá até tristeza ler “The Mythical Man-Month”.

Estou quase acabando de ler o livro “The Mythical Man-Month”, aquele que todo líder deveria ler antes de meter os pés pelas mão em projetos de software. O que achei mais interessante não é tanto o fato dele derrubar o “senso-comum” de que um projeto pode terminar mais cedo simplesmente adicionando mais pessoas (isso vai pro próximo post), mas o fato dele enfatizar que não existem balas de prata, ou seja, não existirá nada que faça a construção de software ganhar um incremento gigantesco de produtividade. Inclua aí as IDEs, a orientação a objetos ou o desenvolvimento visual.

Incrivelmente, os caras da nossa área sentem-se como alquimistas, na busca pela tranformação do ferro em ouro. Rails, por exemplo, é ainda visto pelos noobs como um framework que iria trazer incríveis ganhos de produtividade em relação ao Java. Mas quando o cara começa a “pegar mais” nos estudos, percebe uma coisa incômoda: o framework não traz tanto ganho assim! Só-que não traz mesmo! Software é complexo de se fazer, porque você ainda terá de lidar com espectativas de usuários, com facilidade de uso e com facilidade de manutenção, independentemente de qual linguagem utilizada. (Se bobear, talvez seja esse o motivo da adoção de Rails ser fraca: não é produtivo o bastante.)

Mas ignorar Rails por não ser bala de prata é imbecil demais! É a opção, esquisita, das pessoas que só irão sair da zona de conforto quando a verdadeira bala de prata for apresentada diante de seus olhos. Porém, a solução mágica não existe, né? Meu, Rails é mais produtivo, um pouquinho só, e não é em todas as determinadas situações. Ainda assim, vale a pena aprender, pois a proporção entre legais/idiotas é alto entre os “railers”, ao contŕario dos javeiros. E sua cultura de testes é de invejar qualquer um.

Se ainda não conhece, vai atrás e aprenda. Não deixe o conforto pela espera da solução mágica tomar conta de você.