RailsConf 2008 - DHH vs Spolsky, epilogue

2008 June 05, 14:31 h - tags: railsconf2008 english

Em 27 de setembro de 2006 eu publiquei um post chamado Flame War: Joel Spolsky VS Rails

Nessa época, Rails já estava em ritmo acelerado de crescimento desde o ano anterior. Isso com certeza ‘assustou’ muita gente e os ‘forçou’ a se posicionar. Grandes mestres como Martin Fowler já haviam demonstrado seu suporte ao Rails. Por outro lado, nomes conhecidos como Joel Spolsky deram uma cartada fora do baralho.

No meu artigo, eu descrevo os diversos posts que se sucederam naquela semana, envolvendo Joel criticando duramente o Rails e os vários posts do David contra-atacando. Depois Joel criticando a performance do Ruby e sendo contra-atacado por Avi Bryant e pelo Obie Fernandez.

Pois bem, quase 2 anos se passaram e qual não é minha surpresa ao ver na programação da RailsConf 2008 que o palestrante de abertura do evento é ninguém menos que Joel Spolsky em pessoa!?

Foi uma longa apresentação muito bem conduzida. Preciso dar o braço a torcer, o Spolsky é um orador fenomenal. Quem já preparou uma palestra sabe como a dele foi preparada com muito cuidado. Ele tomou muito cuidado para não mencionar Rails nem uma única vez.

O tema era “o que faz um produto ter sucesso?”

Ele começou comparando produtos. Um exemplo foi o iPod contra o Zune. Blue Chip contra Off Brand. Angelina Jolie contra Uma Thurman. Brad Pitt contra Ian Somerhalder. Brian e Angelina são iPods, Ian e Uma são Zunes. O tom dele foi como se quisesse dizer “eu sei, eu sei, concordo. isso é bullshitagem, um Ian mereceria ser tão famoso quanto um Brad, mas infelizmente não é assim que a vida funciona.”

Os pontos que ele explorou foram:

  • Faça as pessoas felizes – Uma demonstração que achei engraçada foi que ele montou, na apresentação, uma interação com um Windows, (exagerando) sobre como é difícil conseguir extrair uma foto de uma câmera digital, com o Windows abrindo pop-ups esquisitos, pedindo CDs de instalação de drivers e falhando, etc. Ou seja, coisas que tornam as pessoas infelizes. Em seguida demonstrou 2 processos de checkout num e-commerce, no primeiro o estilo ‘quadradinho’ e pouco flexível de ‘wizards’, já o segundo – da Amazon – era uma tela onde você poderia fazer o que quisesse na ordem que quisesse. Segundo Spolsky, é preciso dar ao usuário a sensação de que ele está no controle.
  • Seja obsecado com estética – ele comparou o Samsung Blackjack vs iPhone. Por exemplo, sobre a bateria não removível do iPhone. Ele mostrou como a Apple preferiu não ter um “corte” atrás do fone, ou seja, não ter uma tampa de bateria pela obsessão de ter um design limpo. Não importa que o Blackjack tem mais funcionalidades, o design do iPhone é tão perfeito que “dá a sensação que se eu engolisse ele iria escorregar direto até o fundo.”

Ele foi mais longe e viajou um pouco, falando sobre construções, prédios na França e nos Estados Unidos, e como não ter uma escada de incêndio na frente torna o design mais bonito, ou seja, na França é melhor morrer queimado do que enfeiar a fachada com uma escada. Sobre software, mostrou como coisas como Skins tornam um produto ridículo: se o software não funciona direito não é mudando sua cara que ele ficará melhor. Novamente ele parece pensar “infelizmente as pessoas preferem algo que seja bonito do que algo que funcione. Não brigue contra isso, siga o sistema.”

  • Observe a Cultura do Código – ele discursa sobre percepção. Por exemplo, o Ford Explorer (SUV) contra o Toyota Camry (sedam). 88 pessoas morrem num Explorer por ano, contra 41 no Camry. Porém, a percepção é que o Explorer é mais ‘seguro’ que um Camry. Os SUVs tem ‘cantos arredondados’, airbags em todos os cantos, seguradores de copos e são altos. Eles nos enganam em nos fazer sentir seguros. Daí ele explica sobre ‘atribuição errônea’ ou seja, se você assiste um filme no cinema tomando um bom café, pode ser que diga que o filme foi bom por causa do café. Por outro lado se tomasse algo que não gostasse, diria que o filme foi ruim. Mas isso na realidade não tem a ver com a qualidade do filme, mas sim da reação fisiológica da pessoa.

No fim, parecia que ele queria dizer algo como, não importa se o Rails é bom ou não, mas as qualidades de tornar os programadores mais felizes, ser obcecado pela estética do código e toda a cultura ao redor o tornam um caso de sucesso. Independente se ele ache que Ruby seja lento ou que tecnicamente não haja muita coisa, não é ele quem vai mudar como as coisas funcionam.

Por isso mesmo acho que as reações foram adversas. O Ola Bini por exemplo, acha que não foi grande coisa. Muita gente elogiou o entrenimento, afinal o cara é muito bom apresentador. Mas muita gente também criticou, veladamente, a falta de ‘substância’.

Na mesma linha, no fim do dia, foi a vez do keynote do David Hansson. Ele também decidiu ir pela linha menos técnica e mais conceitual. Acho que ele acredita que finalmente já tem gente suficiente para falar das partes técnicas e ele pode falar sobre coisas que gosta mais. A apresentação de Rails 2, no ano passado na RailsConf Europe, foi ele mesmo quem fez. Mas a de Rails 2.1 foi terceirizada para o Jeremy Kemper, que também fez um trabalho competente.

O David começou falando sobre escolhas. Muita gente ‘reclama’ que Rails os força a fazer as coisas de uma determinada maneira, o tal ‘convention over configuration’. Porém, ele acha que as pessoas gostam mais de ter escolhas do que fazer escolhas. Na sua opinião, um dos fatores de sucesso do Rails é justamente porque ele faz as escolhas que você não quer ter que fazer e, se quiser, pode mudar. Nada impede que você faça as coisas diferentes da convenção, mas se seguí-la é provável que o padrão será o suficiente para a maioria.

Daí falou sobre o ‘surplus’ do Rails, ou o ‘extra’. Ou seja, Rails ainda é uma minoria no mundo de desenvolvimento, mesmo assim ele atrai muita atenção e felizmente hoje existem várias empresas e pessoas que vivem disso. Porém, David entende que esse surplus não vai durar para sempre.

Ele deu como exemplo a cidade de Dubai, que está usando o surplus do petróleo para se modernizar mais rápido do que o normal.

Algumas coisas podem acontecer, a competição pode ficar competente em copiar o Rails; ou algo dramaticamente melhor pode aparecer com um novo paradigma que torne o desenvolvimento ordens de grandeza melhor que o Rails; ou o próprio Rails poderia se tornar o mainstream.

Independente do que acontecer, precisamos usar esse ‘surplus’ para não ficarmos para trás. É como quem ganha uma bolada de dinheiro de uma só vez: você pode gastar tudo ou pode investir. É o que David sugere: que nós programadores temos que investir em nós mesmos.

Ele fala de como Rails ajudou muita gente. Normalmente os programadores precisam trabalhar 110% da sua capacidade, apagam incêndios todos os dias, se perdem na mecânica dessa rotina brutal, ficam fatigados, cansados, desmotivados. Agora, quem se encaminhou no mundo Rails, tem a chance de parar, pensar e agir de forma mais inteligente.

Na 37signals, por exemplo, eles estão investindo nas pessoas. Um dia útil da semana é dedicada para que eles façam o que quiser. Seja programação ou apenas um hobby que nada tem a ver com informática, como artesanato. O que eles entenderam é que iniciativas como essa tornam um programador melhor. E muita gente pode achar isso horrível, “perder 1/5 da semana em hobbies!?” Porém, criar um programador que pode render 10x mais que o normal com certeza vale perder 20% da semana.

E quando se fala em ser 10x mais produtivo não significa fazer 10x mais código. Pelo contrário, significa fazer 10x mais eficiente. Ou seja, codificar coisas que são realmente necessárias, em vez de apenas programar volumes de coisas desnecessárias. Esse é um ponto importante. Na média, um bom programador nunca será ordens de grandeza mais veloz apenas em digitação. Mas um bom programador é aquele que sabe priorizar as coisas, fazer as coisas que interessam primeiro.

Um ponto que meus amigos tiraram sarro na hora foi quando o David disse para “dormir mais!” Ok, eu admito, eu durmo muito pouco. E é claro que o David está certo, ninguém deve tentar ser um superman, eu mesmo não recomendo isso para ninguém. Já está mais do que comprovado que o nível de atenção, foco e, claro, produtividade, cai rapidamente com a falta de sono. No meu caso, minha desculpa é que além de programador eu sou um blogueiro. Vou dizer que é mais difícil ser um blogueiro do que um programador :-) Mas isso varia de pessoa para pessoas, de qualquer forma: “durmam mais!”

Algumas vezes é importante você começar um novo projeto do zero, em vez de apenas dar manutenção num sistema já existente. Ele contou como ele descobre mais sobre o próprio Rails quando pula para criar um novo produto. Ficar fazendo sempre a mesma coisa cansa, é sempre bom começar do zero de tempos em tempos.

Finalmente, outro ponto que eu gosto, compartilhe a mensagem, divida e ensine. Você sempre vai aprender mais quando ensinar. Não tem como ‘perder’ conhecimento quando se transmite conhecimento. Conhecimento gera mais conhecimento. Não deixe de compartilhar.

Portanto, o importante para todos nós entendermos é: esse ‘surplus’ do Rails não vai durar para sempre. Alguma coisa vai mudar as regras do jogo, como sempre acontece. Mas quando isso acontecer, devemos estar preparado para isso. Portanto devemos crescer enquanto programadores. Devemos abrir os horizontes para novas possibilidades, diversificar nossas capacidades, transmitir conhecimento. Enfim, nos tornarmos profissionais completos e não apenas mais um soldadinho de chumbo.

Embora nenhuma das duas palestras, tanto do David quanto do Spolsky não tenham sido técnicas, acho que foi importante porque Rails, mais do que uma tecnologia, é uma cultura. Pessoas como eles divulgam cultura e servem de modelo para todos nós. A mensagem implícita entre as duas palestras, para mim, é que briga de egos, rixas inacabáveis, inveja não declarada e coisas do tipo sempre são nocivas para os dois lados.

Quando o David convidou Spolsky ao palco e este subiu, eu vi um ciclo muito ruim se fechar. A rixa de 2006 ficou em 2006. Ambos são profissionais muito bem sucedidos em seus determinados nichos. Não há razão para haver rancor entre os dois. Tudo bem, Joel começou a disputa, David errou ao continuar. Não sei o que aconteceu por trás dos panos, mas independente do conteúdo das palestras (que no geral foram boas) o gran finale foi bom. Acho que a mensagem implícita foi mais interessante do que o que foi falado.

E isso me leva a Kent Beck, o pai do XP. O Vinicius Telles me disse que já havia assistido ele várias vezes e essa foi uma de suas melhores palestras. O desfecho David/Spolsky que eu disse acima me leva a pessoas como Kent. Um bom profissional precisa trilhar um caminho com desses dois para chegar ao nível de sabedoria de um Kent.

Ninguém é perfeito e não estou querendo dizer que Kent precisa ser endeusado, claro, mas não se pode negar que ele é uma presença forte. Ele é muito espontâneo. Não se ateve a slides. Teve meia dúzia, no máximo, na maior parte do tempo ele permaneceu sentado e contando três histórias de sua carreira. Da mesma forma como você ouviria seu avô contando sobre os bons tempos.

Um ponto que eu lembro porque achei engraçado foi sobre como ele começou com Test-Driven Development (TDD) “resolvi fazer um código que não funcionava, depois codificava o necessário para o teste passar, e fui fazendo assim. Nossa, eu tinha a sensação de estar trapaceando!”

Infelizmente eu não decorei a apresentação toda, ele falou muita coisa e respondeu a várias perguntas da platéia. Espero que alguém tenha gravado, porque o interessante é assistí-lo falar. Normalmente eu prefiro apenas fazer download do PDF e ler os bullet points. Mas no caso de pessoas como ele – que por sinal, sequer tem bullet points nos seus slides – o importante é absorver seu entusiasmo, apreciar sua história. Ali está ele, diante de nossos olhos, um dos pais das metodologias ágeis, falando com eloquência, calma, segurança.

E ele tem um ótimo senso de humor. No final, ele resolveu comentar sobre Zed Shaw. Foi algo na linha de “Entendo que esse sujeito, Zed Shaw, que chamou o Rails de Ghetto, incomodou vocês. Eu li e reli a reclamação dele. Se você considerar como um memorando de negócios, deveria ler somente os dois últimos parágrafos, afinal, qualquer memorando começa com baboseira e só nos dois últimos parágrafos é que estão as partes importantes.” Todos deram risada, claro :-)

“E lendo o final, eu entendi que esse Zed disse que o Rails precisa de um mercado transparente de serviços.” Mais risadas. “Bom, muito obrigado pela sugestão. De qualquer forma, resolvi ler de novo, retirando todos os palavrões, ameaças e coisas do tipo. O que sobrou foi que Rails precisa de um mercado transparente de serviços.” Mais risadas :-D

O cara é fantástico!

Comments

comentários deste blog disponibilizados por Disqus