É algo muito bom que cada desenvolvedor possua sua “stack” preferida de ferramentas. O apreço por esse conjunto leva à dedicação e ao domínio do mesmo.

Entre nós, que orgulhosamente nos categorizamos como “trabalhadores do conhecimento”, creio que, apesar desse apreço à priori não causar prejuízo, trocar de conjunto de ferramentas deveria ser muito fácil (e uma habilidade desejável) já que o que importa é a transformação do conhecimento da forma bruta (dados) à forma desejada (informação), independente do que foi utilizado para isso. É claro que há sempre a curva de aprendizado numa troca dessas: uma nova linguagem, nova DSL/API etc, mas os fundamentos e princípios se mantém.

Nerds, assim como toda pessoa imersa numa sociedade consumista, se definem pelo que consomem e utilizam. Isso é algo bem comum atualmente e vai desde roupas até computadores, editores de texto, smartphones e, pasmem, à p**** da biblioteca que o cara usa pra fazer parsing de XML. Algo que tornou-se muito comum, principalmente com a facilidade que existe para que cada um publique seus pensamentos (blogs, Twitter e afins), é que ocorram “guerras” sobre esse tipo de coisa, já que, em nossa mente, criticar uma coisa que consumo é praticamente criticar a mim e meu modo de viver.

Entre desenvolvedores isso é bem visível. Além das guerrinhas entre comunidades (.NET x Java, Ruby x Python etc) há também as guerras intra-comunidade, em que escolhas de ferramentas são motivo para disputas de ego intermináveis. O cenário, em geral, mostra uma galera que gosta da ferramenta X e acha que, por isso, a ferramenta Y é uma merda inútil e o pessoal que gosta da ferramenta Y achando o mesmo da ferramenta X.

Passemos a um exemplo num contexto diferente para que pré-disposições não afetem nossas conclusões. Imagine que Gordon Ramsay irá a sua casa para fazer o jantar. Ele não vai levar as facas, panelas e demais utensílios que usa em seu dia-a-dia. Vai utilizar apenas o que tem em sua casa. Dias depois você irá a casa dele e utilizará todos os utensílios profissionais à disposição. Bom, a não ser que você seja um anônimo chef de primeira categoria, sabemos quem irá preparar o melhor jantar, não? (sem piadinhas hein! )

Mais um. Quem será que toca melhor: Steve Vai com uma guitarra Giannini de 500 reais ou você com as guitarras ultra-caras dele?

Onde está o conhecimento? Na ferramenta ou no profissional?

Algo bizarro que acontece é ver pessoas que deveriam ter bons conhecimentos sobre lógica confundindo argumento com preferência. Dizer que você prefere X porque acha mais bonito ou mais legal é só sua preferência, não é um argumento para diminuir as alternativas. Chega de “RSpec é mais bonito e moderno, então Test::Unit sucks!” e vice-versa (exemplo aleatório, sem flames por favor).

BREAKING NEWS: se você não sabe patavinas sobre design de código orientado a objeto e uma meia dúzia de princípios básicos, escrever testes em RSpec não vai fazer com que você escreva código melhor do que escrevendo com Test::Unit. Aliás, é bem capaz de piorar as coisas, mas isso é conversa pra outro post.

Em linhas mais práticas, pouco importa para o interessado na informação se ela é processada em PHP ou Ruby, se é formatada em ERB ou HAML ou se está armazenada em MySQL ou PostgreSQL. A ferramenta “certa” é a que faz o trabalho. Sempre há muita discussão sobre isso de “ferramenta certa” e, a não ser que seja algo obviamente errado como usar o Rails pra fazer uma aplicação desktop com controles nativos, o que sempre acaba entrando em jogo é preferência, gosto, estética e etc. Novamente, isso simplesmente não serve como evidência de que algo é superior ou inferior.

“Mas eu sou mais produtivo com X do que com Y!”
“Olha só como meu código fica mais limpo com Z do que com N!”

É, amiguinho. Pra você. Assim como tem muita gente que acredita em divindades criadoras e muita gente que não. Muita gente que acha carros da Porsche bonitos e muita gente que os acha toscos e que os carros da Toyota sim são lindos. Daí a dizer que algum é melhor ou pior é um longo caminho (e, na minha visão, um caminho inexistente).

Pois bem. Por isso creio que, como comunidade, devemos mudar um pouco nosso foco. Tudo bem falar sobre ferramentas, é algo saudável desde que feito com bom senso. Com argumentos, fatos, contexto e harmonia. Não com guerrinhas bobas sobre gosto pessoal e como seu pau é maior que o dos outros sua gem preferida é a mais fodolenta do OMNIverso. É bom para conhecermos alternativas e evoluirmos. Se todo mundo se prendesse ao atual e rejeitasse as novidades, ainda estaríamos perfurando cartões. Enfim, é preciso foco em coisas que realmente fazem a diferença na qualidade. Foco em fundamentos e princípios.

Estatísticas do DataLucas mostram que, a cada dois dias, surgem dezenas de posts falando sobre alguma gem que é a coisa mais maravilhosa já inventada desde o carro voador Toddynho (e que prova que todo o resto é uma merda!), sobre uma miríade de workflows para o VCS da moda, sobre porque a minha biblioteca é mais foda que a sua, sobre como o Agile morreu e, claro, como ele ainda está vivo e funciona muito bem sim senhor!

Legal, todo mundo tem uma opinião sobre o que prefere e sobre o que não gosta. Muito bom, ótimo, sensacional. Mas e o que é imutável? Aquilo que determina qualidade independente do meio utilizado? Já postei bastante essa frase, mas sempre gosto de relembrar:

As to methods there may be a million and then some, but principles are few. The man who grasps principles can successfully select his own methods. The man who tries methods, ignoring principles, is sure to have trouble.

— Ralph Waldo Emerson

Ainda não achei frase que se encaixe mais com meu pensamento sobre desenvolvimento de software. Seja no nível gerencial ou técnico, dominar métodos (ferramentas) ignorando princípios com certeza leva à problema. Manjar de todas as cerimônias e artefatos das metodologias ágeis não vai produzir software de qualidade magicamente. Entender seus princípios, mesmo que você não aplique toda a parafernalha cerimonial, com certeza trará efeitos positivos.

Então fica a pergunta: onde estão os posts e talks sobre princípios? Vamos falar sobre coisas como SOLID (não, não é um besteirol acadêmico), acoplamento, coesão, testes que realmente especificam comportamento, trade-offs arquiteturais e outras questões importantes?

Tentarei fazer a minha parte nisso. Ano passado na RubyConf parte da minha apresentação falou sobre princípios (e outra sobre ferramentas ) e penso em continuar com essa temática tanto no blog quanto em futuras apresentações. Gostaria muito que a comunidade valorizasse mais esse tipo de discussão (wishful thinking…).

Já fiz muito dessas guerrinhas, não sou inocente, mas aprendi a valorizar a base, principalmente abrindo a mente (olha a piadinha!) e dando chances à ferramentas diferentes e, com isso, percebendo que em nossa profissão, felizmente, há vários meios eficientes para atingir os resultados desejados.

And… here comes the flames?

PS: se você é do contra e vai bater o pézinho dizendo que preferência e estética são evidências qualitativas, pode desistir e vaza.

Leitura recomendada: “A Little Knowledge is a Dangerous Thing“

Pausa para explicação.

O modelo Dreyfus de aquisição de habilidades divide os profissionais em cinco níveis de conhecimento para uma dada habilidade (isto é, você pode estar no nível 1 em culinária e no nível 5 em jardinagem, ninguém “é” um nível 5 e pronto). Bem resumidamente, são eles:

1. Novato: o novato precisa de regras claras e independentes de contexto (“receita de bolo”) para guiar seu trabalho, e não sabe lidar com problemas pois não tem experiência para tomar decisões sozinho. Também não toma responsabilidade pelas regras que segue – “Eu estava apenas seguindo ordens!”.
2. Iniciante avançado: começa a tomar decisões mais básicas pois já possui alguma experiência e percebe que pode adaptar algumas regras a certos contextos. Ainda não toma decisões contrárias às regras, não sabe lidar com problemas inesperados e não experimenta a sensação de responsabilidade pessoal. A maioria das pessoas está nesse nível.
3. Competente: questiona as regras de acordo com sua experiência e percebe consequências a longo prazo. Começa a tomar decisões de acordo com o contexto, resolver problemas inesperados e a tomar a responsabilidade sobre seus atos.
4. Proficiente: se utiliza de pouquíssimas regras, começa a valorizar mais sua intuição e sempre analisa o contexto em que está inserido de acordo com o que já experimentou. Sente-se completamente responsável por suas decisões e respectivas consequências.
5. Especialista: o especialista usa a intuição que adquiriu com a experiência e faz tudo parecer muito fácil. Toma decisões e resolve problemas sem esforço, pois reconhece padrões muito rapidamente. É o pior professor para um novato, pois não segue qualquer receita, apenas sabe o que fazer.

Um ponto interessante é que pessoas nos níveis mais baixos costumam se sobreavaliar, enquanto as pessoas nos níveis mais altos são bem mais críticos em relação ao seu trabalho e nível de conhecimento.

Citando Dave Thomas:

So, high-quality experience turns us from a novice to something approaching an expert. We process information in a qualitatively different way in the two states: novices need rules, experts need concepts and contexts. Novices need external feedback, experts generate their own. Stuff that works when teaching a novice drives an expert up the wall, and vice-versa. Experts are often the worst teachers of novices.

Este modelo foi utilizado na década de 80 para resolver alguns problemas na profissão de enfermagem, problemas esses que são agora enfrentados pelos desenvolvedores de software: a profissão não é valorizada (sendo considerada simplesmente operacional), os salários são baixos (o que torna mais interessante financeiramente dar palestras/consultoria ou partir para cargos administrativos), a educação de novos profissionais piora cada vez mais (devido à sobrevalorização de modelos formais e desvalorização da experiência prática) e a perda de visão do real objetivo (satisfazer aos clientes ao invés de simplesmente “fabricar” software).

Voltando:

Tudo o que você precisa fazer para arruinar o trabalho de um especialista é fazer com que ele siga regras. É o que Andy Hunt chama de “arrebanhar cavalos de corrida”. Para arruinar o trabalho de um novato, deixe-o livre de receitas, o que Andy chama de “colocar ovelhas para correr”. É por isso que metodologias e regras não podem ser aplicadas a todos em uma equipe: equipes são heterogêneas, possuem profissionais em vários níveis de conhecimento em uma dada habilidade. Os chamados “gestores de pessoas” simplesmente não conseguem perceber isso, ou fingem não perceber.

Outro fator que atrapalha é acreditar que todos devem ser tratados da mesma forma ou haverá insatisfação: dado que os tratamentos diferenciados não sejam coisas absurdas e seja deixado bem claro que qualquer um que se torne mais experiente pode alcançar os benefícios, não há problema nisso. Basta haver transparência.

Esses mesmos gestores ignoram a intuição dos especialistas e usam a justificativa de que não é científico ou não segue a metodologia XYZ. Desta forma, forçam seus melhores profissionais a seguir regras que não fazem o menor sentido para eles. Resultado: insatisfação, baixa produtividade, qualidade do trabalho acaba menor do que poderia ser e, finalmente, a perda do profissional. Basicamente, pagam mais para os especialistas e desperdiçam o que os torna diferentes. Não é assim em todos os lugares mas, infelizmente, é o que acontece na grande maioria.

Escute seus especialistas. Dê espaço àqueles que já provaram seu valor e são referência dentro de sua equipe. Ignore o senso de “politicamente correto” e, sim, trate os desenvolvedores de sua equipe de forma diferente, de acordo com o respeito natural que surge dentro da equipe em relação aos melhores e mais experientes. Lembre-se que métodos formais não alimentam criatividade, intuição e inventividade. Não há “tamanho único” quando falamos de experiência e competência.

Referências:
Dave Thomas – End of the Knowledge Worker?
Andy Hunt – Pragmatic Thinking and Learning: Refactor Your “Wetware”