Já dizia o ditado popular: mais vale um pequeno focado do que um grande estabanado. O Microsoft Windows Vista, anciosamente aguardado por quase todos os usuários Windows, revelou-se um gigante estabanado, lento e comilão. O sentimento de anciosidade transformou-se rapidamente em repúdio, assim como ocorreu com os fãs do XGL. O público percebeu que enfeites atrapalham muito mais do que ajudam. KDE 4 que se cuide.

Felizmente, esta lei não se remete apenas a enfeites, no sentido gráfico da palavra. IDEs como Eclipse, Netbeans e Delphi, sofrem frequentemente da mesma mazela, ter adicionado features desnecessárias ou com baixa utilidade para a maioria de seus usuários. Como se já não fosse ruim, estas features consomem memória, processamento e a paciência do desenvolvedor. Quem já não se viu puto com os MemoryLeak do Eclipse ou aquela demora excessiva em uma operação simples? (Abrir um arquivo, por exemplo?). Quantos de vocês já não tiveram vontade de entrar no core de um software e remover tudo o que é desnescenessário?

O MonoDevelop, que eu uso em um dos meus projetos, é simplesmente uma das melhores IDEs que eu já vi. A razão é bem simples, eu só preciso de quatro coisas: Árvore de projetos, syntax highlight, SVN e code completion. Só. Estas são as features que me trazem produtividade, o resto é enfeite. O MonoDevelop não tem nada além destas 4. Por que diabos eu preciso do servidor de aplicações e do browser rodando dentro da minha IDE? Ou, por que diabos eu preciso de um UI Designer dentro da IDE, se eu uso ele apenas em alguns instantes? Perguntas interessantes, não? Depois do Eclipse 3.3 que veio com uma Spelling mais lenta que o próprio compilador, as coisas inúteis do Eclipse ficaram mais claras. Você pode desabilitá-las, mas isso não torna a IDE mais leve.

A comunidade Java, como um todo, está experimentando o seu momento Golias. A infinidade de bibliotecas que existem para resolver o mesmo problema, assusta os iniciantes e os mais experientes. Como a grande maioria delas atinge o seu objetivo, soluciona um problema, a diferença entre elas é apenas detalhe. Diferenças que podem ser importantes para aumentar a produtividade de um time (a interface com o desenvolvedor, por exemplo) ou que simplesmente não fazem diferença alguma (como saber se é action-based ou component-based). Um bom profissional analisaria todas as opções disponíveis antes de tomar uma decisão mas, por exemplo, em frameworks MVC-Web Java open-source (repare como é específico), existem tantas opções que é impossível fazer esta análise. Obviamente este é o pior caso, mas outras categorias também já estão preocupantes.

Se você acha que eu iria perder a oportunidade de criticar todo mundo, está enganado. Muitos profissionais avançados e mais experientes não se dão conta deste problema e se tornam verdadeiros Golias, grandes mentes estabanadas. A prova que o ditado pode ser aplicado nesta ocasião é que, por diversas vezes, funcionarios mais novos e focados (aka estagiários) são mais produtivos (quantitativamente e qualitativamente) do que os mais velhos. O pior de tudo, é que os estabanados Golias acham que tê-los trocado por gente mais nova é um erro do gerente, afinal é ele quem vai perder qualidade quando, na verdade, o erro foi terem ficado grandes e inchados. A arte de pensar em inúmeros problemas antes da implmentação é extremamente prejudicial para solucões simples. Pense nisso.

O ditado também serve para explicar como VI, Rails, Gtalk e próprio Google fazerem tanto sucesso. Simples, produtivos e focados. Você quer ser Davi ou Golias?