Em 1926, George Taylor, um economista americano, formulou a teoria do “Hemline Index“. A teoria correlaciona o comprimento dos vestidos da mulheres com a saúde da economia: quanto mais curto o vestido/saia, mais forte a economia.
Nos anos 40-50 a moda eram saias longas, até o tornozelo. A exuberância dos anos 60 veio com os mini-vestidos e o surgimento das mini-saias. A recessão e a crise do petróleo nos anos 70 aumentou o comprimento da roupa feminina, que diminui novamente no início dos anos 80. Na recessão que iniciou em 1987, fez com que a moda das longas saias e vestidos aumentasse novamente, até serem reduzidas novamente nos anos 90. No mínimo é uma estranha coincidência, certo?
Esta teoria foi validada e revista por Terry Pettijohn, um professor de psicologia na universidade da Carolina (EUA) e por vários outros pesquisadores e institutos de pesquisa de comportamento de consumo. Um resumo muito interessante está resumido neste artigo do jornal New York Times, de agosto de 2008. Desmond Morris utilizou esta teoria como base do seu livro “The Naked Ape“.
Nosso comportamento muda muito de acordo com a situação econômica. Isto já é um fato comprovado. A venda ou não de alguns itens só pode ser explicado por estes “up” e “down” da economia.
O que isto tem a ver com java?
Rod Johnson é um dos líderes da comunidade Java e Java EE. Ele é autor de livros importantes como “Expert One-on-One J2EE Design and Development (2002)“, “J2EE without EJB (Julho 2004, com Juergen Hoeller)“, “Professional Java Development with the Spring Framework (Julho, 2005)”.
Mais um detalhe. Ele é o idealizador do Spring Framework, indiscutivelmente, um dos melhores frameworks Java.
Foi ele quem apresentou um o gráfico ao lado que, utilizando o “Hemline Index“, expõe seu ponto de vista na tentativa de explicar, porque a plataforma Java tornou-se tão complexa.
Veja como temos uma tendência a complicar as coisa – como o comprimento longo das saias femininas -, quando a economia vai mau. E a complexidade diminui nas crises, como esta de 2008/2009.
Ele apresentou suas idéias durante o evento QCon, London 2009. É uma palestra de pouco mais de 1 hora onde ele explica, com exemplos, alguns motivos que inseriram complexidade na plataforma Java.
Uma das razões é a abordagem de decisão por comitês, utilizado na JCP, que precisa “dar a benção” em toda mudança na linguagem.
Antes de mais nada, eu concordo com o ponto de vista colocado na apresentação. Não leve em conta minha opinião, ou mesmo do autor da apresentação: veja os fatos, os argumentos e tire suas próprias conclusões.
Meus R$ 0,10 na discussão. Como tudo na vida, a decisão por comitês (innovation by committee) é um processo de “trade-off“: ao controlar e burocratizar todo o processo de mudança, eu estou permutando estabilidade por uma menor inovação. É assim com as decisões do JCP e de todo comitê que você criar na sua empresa para controlar mudança.
Veja que isto não é necessariamente ruim. O ponto da discussão não é este. Existem épocas em que as saias são longas e em outros elas são curtas. Mas, tudo tem seu preço. No caso da plataforma Java, o preço foi o incremento de uma complexidade desnecessária.
Você quer saber algumas das razões?
Assisti a palestra do Rod Johnson e fiz um resumo. Se você se interessa pelo assunto, assista a palestra (1h 3min) ou leia meu resumo a seguir.
Que lições podemos tirar dos últimos 10 anos de desenvolvimento da linguagem Java?
Foi assim que R. Johnson iniciou sua palestra. Vou resumi-la em forma de bullets para simplificar a leitura.
Que lições podemos tirar dos erros no desenvolvimento da plataforma Java nos últimos 10 anos?
Dois fatores se destacam:
- O poder que os desenvolvedores tiveram com Java
- Flutuações na economia
- Java iniciou como uma linguagem fácil (ao contrário do que muitos acham), era como “C++–”. Mesmo hoje ainda é simples.
- O DNA de Java é a simplicidade
- O problema não é a linguagem em si. A complexidade foi introduzida ao longo do caminho
Um dos erros foi trazer o “Enterprise” para a linguagem. À esta palavras, em qualquer abordagem, está associada a complexidade. Quem se lembra das “Entity Beans”?
- A complexidade da indústria. Grandes companhias, como IBM, terem “abraçado” Java também tem pontos negativos. “É simplesmente impossível IBM adotar uma tecnologia e não complica-la”, de acordo com R. Johnson
- Abordagem “No pain no gain” (convenhamos, isto é uma falácia)
- Era legal ser complexo. Como desenvolvedor sou diferenciado (isto valeu no início)
Como J2EE evolui para Java EE
- Nos anos 90 Java começou a migrar para o servidor.
nota do autor do blog: Você já programou um “Applet”? Eu já! E utilizava o Notepad! (como sofremos…)
-Não existia muita “regulamentação” para a linguagem (nem havia muitas razões para)
-Ambiente de muita competição: ToLink, Apple WebObjects etc
O Bom e o Ruim
- Muita inovação, muitas opções (bom)
- Mercado de “server-side” era muito fragmentado (bom)
- Risco de ficar “preso” a um fornecedor (ruim)
- Muitas soluções caras (preço da inovação, ruim)
1999 – 2003
- Especificações começam: JCP
- Non-standard não podiam competir com uma plataforma J2EE padronizada:
- ORM versus EJB entity beans
- Velocity versus JSP
- WebObjects versus web tier
1999 – 2003: Bom e Ruim
- Cria-se um grande mercado
- Fornecedores com opções fechadas diminuiram, mas não foram eliminados
- Controle (JCP) estrangula a Inovação
- Idéia de que todos os business objects (EJB) deveriam ser distribuídos
- 2003: início de aplicações Java “leves” (lighter-weight solutions). Exemplo: a adoção em massa do Tomcat
- Os projetos open-source ajudaram a definir o futuro da plataforma e trouxeram inovação: Eclipse, Spring, AspectJ
As “armadilhas” ou Ideas que trouxeram complexidade no J2EE
- Design by committee: tudo precisava ser padronizado. JCP fala de forma privada; composto de grandes fornecedores de software
- Ferramentas que traziam excessiva complexidade
- Não abertura para outras plataformas, a abordagem “Java puro sangue”
- “Desenvolvedores são estúpidos e devem ser controlados”
- “Soluções complexas são melhores”
- “Eu preciso de uma solução que habilite minha arquitetura corporativa”
Os comitês queriam padronizar tudo em Java. Uma verdadeira obsessão do JCP. Citando, Jim Waldo, um engenheiro da Sun:
Reverenciando tudo de bom que os padrões nos trazem, eu acredito que, de certa forma, trazem um grande dano para nossa indústria e a ciência. Ele transforma discussões técnicas em debates políticos. Isto gerou um problema de entendimento do verdadeiro significado dos padrões. Pior de tudo, nos levou a fazer escolha tecnológicas absurdas, que nunca haviam sido implementadas e que não eram a escolha adequada para os problemas que tínhamos em nossas mãos
Exemplos do que foi dito acima:
- CORBA (1990s)
- CMP entity beans
- Muitos ignoraram o sucesso do “TopLink”
O bom exemplo do Linux
Linux é um exemplo de inovação que não fica restrita aos processos de padronização, que são restritos ao Kernel. Na minha opinião, se o processo de desenvolvimento do Linux fosse semelhante ao do Java não teríamos uma distribuição como o Ubuntu.
Qual deveria ser o papel do JCP?
Criar um “mercado” onde as inovações podem ser desenvolvidas a partir dos padrões. Inovação a partir de comitês (innovation by committee), historicamente, produzem resultados medíocres.
Por que a complexidade é “boa”?
- Temos uma tendência natural de achar que “sem dor não haverá ganhos”, ou o adágio “no pain no gain”
- Síndrome da “Nova Roupa do Imperador”, ou seja, “não entendi muito bem, é muito complexo, então deve ser bom!”
“É a economia, estúpido!”
[nota do autor do blog: você já leram várias vezes esta frase aqui. E ela é citada por Rod Johnson como um dos motivos de mudanças no horizonte da complexidade. Veja o post sobre a versão 6 da plataforma Java]
- Em um cenário de pós-recessão temos que repensar os investimentos. Economia, economia.
- “Hemline Index”
Economista americano, George Taylor (1926). Relacionou a “exuberância irracional” de nossas ações (pessoas e empresas), com a exuberância da economia.
Inovações da comunidade que fizeram diferença
- Spring
- Hibernate
- Ruby on Rails
- Django
- Grails
Da comunidade open-source para simplificar a vida dos desenvolvedores!
Previsões
- Não teremos um retrocesso para um sistema com complexidade desnecessária
- Portfolio complexos não tem mais espaço. Foco na agilidade, simplicidade. Economia, economia.
- Processo Ágeis vieram para ficar
- Desenvolvedores ainda terão, e precisarão ter mais poder e mais responsabilidades
- Ainda é necessário termos uma plataforma Java que permita uma maior produtividade
- Tradicionais aplicações residentes no servidor cairão em desuso
Resumo
- A pessoa-chave para as mudança é o desenvolvedor
[nota do autor do blog: o desenvolvedor, o arquiteto tem que exercitar o Pensamento Crítico e não aceitar a complexidade simplesmente porque algum comitê, mesmo que seja o JCP, assim o definiu]
- Veja as alternativas, simplifique, estude e tire suas próprias conclusões. Não utilize uma solução porque alguém decidiu que esta é “a” solução
A editora O’Reilly acaba de lançar o livro “97 Things Every Programmer Should Know“.
