Adoção Enterprise
Josh me perguntou hoje como “vender RoR para equipes que estão acostumadas a trabalhar com Java/J2EE”. O maior desafio, na minha opinião, é que muitas equipes fazendo J2EE têm pessoas acostumadas a pensar que rápido == sujo. A palestra de Martin (Martin Fowler, claro) tem toneladas de boas informações para qualquer um querendo evangelizar Ruby como catalisador de soluções rápidas e limpas, e aplicações Rails bem escritas tem tudo a ver com rápido e limpo. Um bom aplicativo J2EE é lento e limpo, mas a maioria é lento e sujo. Acho que a coisa mais difícil sobre convencer desenvolvedores J2EE hardcore seria que muitos deles, na realidade, atacam a complexidade construindo framework atrás de framework. A maioria das pessoas de Java que conheço não são desenvolvedores de aplicativos! Eles são programadores e gostam de trabalhar no encanamento! Você não conseguirá vender Ruby on Rails para essas pessoas (nunca?), porque Rails é primariamente usado para coisas de front-end, que eles odeiam. Claro, estou generalizando, mas é bom ir devagar e levar em conta os preconceitos das pessoas.
Equipes J2EE tendem a ser grandes, por causa da complexidade extra. Grandes projetos normalmente dão liberdade aos membros para performar abaixo de suas habilidades e/ou patinar trabalhando em projetos de brinquedo e qualquer outra bobagem que não adiciona valor ao negócio. De novo, vá devagar nessas situações porque quando você tentar vender Ruby on Rails para esse tipo de pessoa eles serão bastante negativos. Você representará uma grande ameaça à felicidade deles (nota do Akita: de procrastinar).
Por outro lado, existem pequenas equipes por aí fazendo Java e .NET que estão comprometidas com o sucesso do seu negócio e/ou realmente podem ser considerados desenvolvedores de aplicações. Esse pessoal deve ser bem fácil de convencer para o lado de Ruby on Rails. Eles realmente gostarão dos benefícios e tirarão o máximo proveito disso.
Nota do Akita: Obie se refere a “pet projects” que traduzi como “projetos de brinquedo”. Muitos programadores se desvirtuam do escopo (e do cronograma!) do projeto e acham que podem fazer alguma coisa melhor ou diferente mas que realmente não tem valor algum. Alguém acha que o jeito como Struts faz validação não é legal e resolve fazer um novo framework só pra isso. Ou pior quando alguém decide que o cliente deveria ter um contador de visitantes na página principal, ou coisa parecida. Igualmente inútil.
Obie também se refere a outro termo conhecido na área: programadores que gostam de “plumbing”, que traduzi como “encanamento”. Quando ele diz que a maioria dos programadores não são desenvolvedores de aplicação mas sim de framework, é a consequência do sintoma de não existir frameworks eficientes que cobrem a maioria das atividades, por isso o programador se sente mais confortável escrevendo seu próprio framework. Só que ele faz isso em todos os projetos, começando do zero o tempo todo. A maioria nem percebe porque se tornou parte da rotina. A maioria também não percebe quão improdutivo isso é. Também é de onde vem a maioria dos bugs e dos desperdícios de tempo. Quando você um bom framework, o plumbing já está feito. Não há necessidade de reinventar a roda o tempo todo.
A ThoughtWorks é uma grande consultoria que desenvolve projetos internacionalmente. Não são nenhuma IBM mas tem como principal integrante, Martin Fowler, escritor de diversos livros que a maioria dos arquitetos de sistemas deve conhecer, principalmente os de UML e mais recentemento sobre o movimento Ágil.