A palestra de ontem (Apresentando Rails 2.0, apresentada pelo o Fábio Akita e organizada pela Impacta), valeu a pena não só para aprender o que é Rails, ou ver como ele funciona.

Serviu para reforçar a minha idéia de que, aos poucos, está surgindo (ou ressurgindo, não tenho tanto tempo de programação assim pra saber) uma nova classe de programadores: os que são responsáveis pelo trabalho que fazem, não se escondem atrás de alguma documentação mal-feita e/ou gigantesca e/ou complicada e/ou indecifrável; participam ativamente do processo de criação do software, junto a todos os interessados, não ficam se escondendo atrás de um analista-culpado e buscam a melhor solução que funcione.

E também para reforçar outra tendência que tenho notado em diversos artigos, tutoriais e apresentações como a de ontem: a de que os programadores que usam linguagens "dinâmicas" (Python e Ruby, por exemplo) incorporam muitas práticas ágeis de desenvolvimento no processo de construção do software.

Hoje em dia a velocidade de desenvolvimento de software tem que ser a mesma da velocidade dos negócios. E desenvolver software é, pra muita gente, um processo engessado, com muita documentação, muita pré-analise, muita estruturação; muita engenharia para se chegar em algo que teoricamente atenda a um certo propósito, que muitas vezes é exagerado, abrangendo muito mais do que o necessário. Teoricamente, porque nada daquilo ainda funciona, nada foi provado.

E esses "novos" programadores querem fazer software que funcione, e logo. Querem saber o que o cliente quer, e atender a estas necessidades. Algo simples e poderoso, que gere retorno para o cliente em pouco tempo de desenvolvimento. E usando ferramentas que não atrapalhem esse processo rápido. O tempo entre a idéia e o programa deve ser o menor possível.

Fica difícil pensar em desenvolver software rapidamente com a burocracia que as metodologias clássicas impõem. E como desenvolver software rapidamente com linguagens tão verbosas e tão engessadas, que exigem tanto trabalho manual e também o conhecimento de uma estrutura hierárquica de classes para efetuar operações simples como gravar um arquivo em disco?

Por isso, a simbiose entre linguagens dinâmicas e métodos ágeis. Para mim, era natural que isso acontecesse, principalmente porque o programador que começa a usar uma linguagem dinâmica quer velocidade, quer "fazer funcionar" logo, com pouco trabalho manual.

E para desenvolver um sistema dessa forma, ele tem duas alternativas: ou senta e começa a digitação de código sem qualquer planejamento, projeto ou até mesmo idéia do resultado final e se frustra ao final do processo vendo a porcaria feita; ou usa um mínimo de práticas que organizam o seu trabalho (práticas como as do XP, por exemplo) e desenvolve algo que funciona e atende às necessidades.

Para novos tempos, novas pessoas e novas idéias. Outras idéias sempre estarão por aí, cada uma com o seu modelo de funcionamento e atendendo muito bem o mercado em que estão inseridas (Mainframes/COBOL é um bom exemplo).

Mas não dá pra manter as mesmas idéias e atitudes para viver em novas realidades. Esse pessoal entendeu o recado, e agora mostra como se faz.