A Ecologia, a Sacola e a Cultura

A partir do dia 25 de janeiro de 2012 uma nova lei permite que as loja cobrem pelas sacolinhas plásticas com que os clientes transportam as compras para casa.

As lojas querem que você acredite que deixarão de haver sacolas disponíveis nas lojas e tentam convencê-lo a comprar aquilo que chamam de “sacolas ecológicas” . Não vou sequer abordar o fato de muitas dessas sacolas conterem plastico, e de não serem de fato ecológicas… adiante. O ponto é : as lojas estão tentando convencer que ou você compra sacolas reutilizáveis agora, ou você vai começar a levar as compras para casa nas mãos.Mais do isso tentam você se sentir mal por usar sacolas plásticas agora responsabilizando o seu uso das suas sacolas pelos problemas ecológicos do uso do plástico e do não tratamento do lixo que são problemas mundiais.

Tudo estaria bem se as lojas realmente deixassem de usar sacolas plásticas e mudassem para o papel ou o tecido. Assim, ou você leva uma sacola reutilizável (não confundir com renovável) de qualquer material que você quiser ou você sai da loja com as compras não mão. Ora isto seria surreal. As lojas perderiam os clientes de oportunidade. Aqueles que não são clientes habituais e entram por impulso ou necessidade pontual.

A verdade é que as lojas continuarão a ter sacolas disponíveis. Mas por um preço.  A mudança não é na disponibilidade das sacolas plásticas, é no seu preço. Agora você terá que pagar por elas. Ninguém se engane achando que esta é uma atitude ecológica. É uma atitude econômica. Se o cliente tem que pagar pelas sacolas ele será mais cuidadoso a arrumar as compras nas sacolas e não usará uma sacola para cada item como muita gente faz. Além disso o custo da sacola é repassado ao cliente em vez de custar à loja. Basicamente a politica é : Quer uma sacola plástica ? Compre-a.  É bem diferente do que eles querem fazer parecer no marketing que seria “Quer uma sacola plástica ? Não temos. Porque defendemos o meio ambiente. “

Ora, se as lojas continuam tendo sacolas plásticas disponíveis, mas por um preço, então afinal como fica a ecologia ? Onde sempre fica : na carteira. A conclusão a tirar daqui é : você pode usar sacolas plásticas, desde que as compre. Se você pode poluir o mundo, desde que pague.

Mas o problemas não é apenas das lojas de produtos comestíveis. Todas as lojas estão tentando vender suas sacolas reutilizáveis com branding. Branding é uma estratégia em que se associa qualquer produto a uma marca. No caso a marca da loja. Neste espírito livrarias estão adotando a estratégia comercial de vender sacolas reutilizáveis.

Hoje entrei numa livraria cultura, com minha esposa, para comprar alguns livros. De vez em quanto dou uma olhada para ver o que ha na prateleira sobre desenvolvimento. Depois disto decidimos que queriamos comprar algumas sacolas reutilizáveis. Não pela pseudo-preocupação ecológia mas pelo simples fato de ter sacolas rutilizáveis. Pegamos duas sacolas de um modelo mais barato e outra de um modelo mais caro. Quando a moça do caixa passou os produtos o computador mostrou uma com preço diferente. A sacola custava 17 reais e o computador apontava 10 reais. Pelas regras do código do consumidor a loja é obrigada a vender pelo menor preço. Contudo a caixa não queria fazer isso nem consegui explicar porque o preço era diferente. Mas em vez de ativamente resolver o problema disse que tinhamos que falar com um vendedor. Claro que neste ponto já havia uma fila à espera. A loja em questão tem vários caixas no centro da loja em circulo. É simples para os clientes mudarem de fila, mas ninguém fazia isso.  Porque a fila tem que andar, a caixa usou a estratégia de nos mandar com um vendedor para resolver o problema. Dessa forma ela poderia continuar atendendo o resto da fila. Ora, você está sendo lesado pela loja, as pessoas têm opção de ir a outros caixas, porque cair nessa ratoeira. Eu fiquei e a minha esposa caçou um vendedor na multidão. O vendedor informou que se tratava de uma promoção. Porque eramos associados do programa de clientes e tinhamos crédito podiamos levar a sacola por dez reais. Agora o ponto era outro. Como saber se essa promoção realmente existe ou é uma desculpa para a divergência de preços ? Perguntamos então sobre onde está publicada a promoção. Toda a promoção tem que ser publica, ou seja, deve haver um cartaz um informativo qualquer e algum documento sobre as regras. Esta simples questão levou o vendedor a pedir que uma terceira pessoa – que se apresentou como a gerente – a intervir. A gerente repetiu o mesmo discurso do vendedor. Peguntamos pelo regulamento. Ela foi buscar. Esperamos. Enquanto esperávamos a fila estava travada e as pessoas começaram a mudar de fila. Claro que zangados. Connosco! Como se a culpa de falta de explicações fosse de quem faz as perguntas. Perguntamos à caixa sobre o exemplar do codigo do consumidor que a loja deve ter disponível para consulta. Queríamos mostrar do que estávamos falando. Não é questão de 7 reais de diferença. É a questão da relação fonecedor-consumidor. Para nossa surpresa ela não tinha um. Uma empresa como a Livraria Cultura, não era de esperar.

A gerente regressa. Sem o documento. Pedindo para irmos com ela a um ponto de consulta de preço. O objetivo é duplo aqui. Primeiro tirar-nos dali e fazer a fila andar. Repare que ninguém está preocupado com o que estamos dizendo, apenas em fazer a fila andar. Por outro lado queria mostrar que o preço padrão era 17. Tentei explicar para ela que eu sabia que o preço era 17 na consulta. Eu tinha feito essa consulta antes. O ponto não era esse. O ponto é que o computador do caixa, dizia um preço menor. A lei diz que tem que ser o menor preço anunciado. Não importa onde. Se é no totem de consulta ou no caixa ,ou num panfleto…

No impasse a gerente perguntou o que queriamos. Dissemos que queríamos compras todas as sacolas pelo menor preço, a menos que nos fosse apresentada a divulgação da promoção. Ela não conseguiu fazer prova da promoção e disse que nunca venderia pelo menor preço e que se não queriamos pagar pelo preço que o computador mostrava, deveriamos ir embora. Assim fizemos. Cancelando a compra. Fazendo uma reclamação por escrito. Finalmente a fila estava livre e andando. Era só esse o objetivo.

Na saida perguntámos ao segurança o nome do gerente. Queriamos aferir se era realmente a pessoa com que falámos. Ele falou para nossa surpresa que não existe um gerente. Que se tivessemos algum problema ele poderia chamar o atendimento ao cliente. Alguns detalhes. Enquanto esperávamos ligamos para dito atendimento. A pessoa estava nos vendo, mas não veio atender ou ver o que era o problema. Ambos vendedor e pseudo-gerente asseguravam que a promoção estava no site da Livraria Cultura. Ao chegar a casa verifiquei que não havia qualquer menção a qualquer promoção e o preço no site era 17 reais.

O maior choque é a falta de transparência. Ninguém sabe de nada. Só importa liberar a fila.E as pessoas afirmar ter cargos que nem existem…

Hoje mesmo na secção de desenvolvimento tinha um livro dobre HTML5. O único da loja. Em péssimo estado. Em qualquer loja competente aquele livro não estaria ali ou seria substituído por um em condições, ou um desconto seria dado. Afinal quem quer gastar dinheiro num livro completamente maltratado ? Perguntei ao vendedor se poderia aranjar outro exemplar ou dar um desconto. O que ele fez? Saiu sob a desculpa que iria ser se era possivel dar um desconto. Voltou dizendo que aquele era  o único exemplar e não havia desconto. Ok. É um direito da loja. E o meu direito é não comprar. Só não precisava de todo o teatro. Bastava dizer que não havia latitude para dar o desconto da primeira vez que perguntei.

Estão vendo o padrão ? Sair de perto do cliente sob a desculpa que vai resolver o problema e voltar sem ter feito nenhum esfoço. Qualquer esfoço. Nada. E esperar que o cliente tenha mudado de ideias ou tenha ido embora. Afinal o que faz uma livraria ? Vender livros ? Não.

É possível acreditar que empresas que nem saibem cuidar do seu negocio saibam cuidar da ecologia ou sequer saibam o que isso é ? Não. O que é muito fácil de acreditar é que as empresas e lojas de hoje em dia estão preocupadas apenas com lucrar. E lucrar significa vender mais e ter menos custos. Não importa que um cliente foi coagido a sair da loja sem o produto se um 50 outros formavam fila atrás dele.

É isso que me custou tentar comprar uma maldita sacola reutilizável …

Mas a historia não acaba aí. No caminho de casa passei num supermecado da rede Pão de Açucar onde comprei 3 sacolas de melhor qualidade por menor preço (13 reais). Um lugar onde todas as perguntas sobre o evento do dia 25 foram respondidas competentemente pelos funcionários.

Não é esperar muito que sejamos bem tratados como consumidores. Afinal damos um duro danado para ter esse dinheiro para gastar nas lojas. O minimo é que nos tratem bem.

Podem até enganar-nos com um papo ecologista que nos obriga a comprar sacolas reutilizáveis, mas querer fazer de nós estúpidos é pedir de mais. Eles estão se ajudando a si mesmos. A lei só torna isso oficial.

Respeito. É pedir muito ?

Economia Verde, Economia Vermelha

Ha um ano que não escrevo para este blog. Não que não haja uma miríade de assuntos para escrever, mas porque me falta o tempo físico e mental para o escrever. Mas hoje, me ocorreu um pensamento que não posso deixar passar em branco.

Hoje em dia, é quotidiano ouvir falar sobre “verde”. Empresas verdes, produtos verdes, etc… Todos querendo salvar o mundo e natureza dos maus tratos que a humanidade lhe causa.

Sendo educado em ciências isto só por si me causa grande náusea, porque demonstra como a população mundial pode ser tão facilmente enganada pela mídia. Não ha realmente provas que exista realmente um aquecimento global, tal como não havia das causas do buraco do ozônio que todos já esqueceram  mas que ainda permanece lá. Quem existe para dizer que aquele buraco não é natural e sempre esteve ali. As “estatisticas” dizem que o globo está aquecendo cerca de 1ºC por século. Sendo que o termômetro foi inventado 1592 mas apenas no final do seculo XVIII se começaram a fazer medições periódicas na Inglaterra sendo que medição periódica em todo o mundo apenas foi conseguida no seculo XX.  Ou seja, um único século para medir o aumento de um grau por século. É como olhar o termometro durante uma hora e vê-lo subir 1ºC e concluir que a temperatura irá aumentar 1ºC por hora. O que realmente não leva em consideração o fato que essa mesma temperatura poderá não aumentar no período seguinte.

Muita gente ainda acredita que o nível das águas do mar irá aumentar quando os glaciares dos polos derreterem. Como uma experiência bem simples lhe mostrará , o gelo ocupa mais espaço que água liquida, o que significa que quando o gelo se transforma em água, o nível da água diminui. O que significa que o argumento é furado.  O nível da água do mar aumenta devido à dilatação da água e não ao descongelamento dos gelo. Faça a experiência. coloque gelo num copo e encha com água. Marque o nível da água. Espere o gelo derreter e marque de novo. Observe que o nível marcado no final é menor que o anterior.

Pois bem, no meio de toda este manbo-jambo feito para enganar a população a pagar mais pelos produtos , serviços e marcas “verdes” achando que estão salvando o mundo, mas que no fim, estão sendo apenas enganadas do seu dinheiro ha um problema mais grave.

Quantas dessas marcas, produtos ou serviços são manchados pelo trabalho escravo que é utilizado na sua fabricação. Não é  segredo para ninguem que não existem leis trabalhistas em muitos dos países asiáticos e que é exatamente lá que os produtos de marcas famosas são fabricados. Desde marcas de roupa e calçado e marcas de produtos de informática e aparelhos domésticos são fabricados por pessoas em condições de trabalho deploráveis e até por crianças e até de escravidão.

Então , quando você compra um produto e se pergunta se ele é verde e se os seus produtores se procuram com a Natureza , você também se pergunta como aquele produto foi feito e quantas crianças ou escravos o produziram ?

Você se preocupa que o produto é verde, mas não se ele é manchado pelo vermelho do sangue destes injustiçados ?

Porque você acha que o mundo está em uma crise econômica ? Porque milhões de pessoas não têm poder aquisitivo. Pode este que perderam quando as suas funções foram transferidas para pessoas na Ásia que recebem menos, ou mesmo nada e até crianças. E esses mesmos produtos são vendidos mais caro aqui do que antes. As marcas irão negar que empregam crianças ou escravos, mas todos nós sabemos que isso é mentira. Negabilidade significa que se pode negar, não que é mentira.

Os países  do chamado primeiro mundo não podem competir com isto. Não ha como competir com produção de custo zero. A não ser que as pessoas deixem de comprar os produtos produzidos dessa forma. Da mesma forma que se pede o boicote a produtos não-verdes porque ferem o ambiente e o legado que você irá deixar aos seus filhos, também os produtos vermelhos afetam o legado que você irá deixar aos seus filhos. Um mundo onde é licito alguns se aproveitarem da fragilidade dos governos para se utilizarem das pessoas a um nível criminosos, mas o outro lado do mundo não sabe, não enxerga e não quer saber sobre o problema.

Comparativamente queimar pretróleo é muito menos perigoso do que comprar estes produtos de marca manchada.

Você vai ler este texto e até poderá concordar com ele e falar dele aos seus amigos e tentar conscientizará-los do problema que a probreza do terceiro mundo se deve ao consumismo do primeiro e que a crise do primeiro se deve à falta de evolução do terceiro. Ou seja, a desigualdade é o motor para mais desigualdade.

Pessoas se procuram com o ambiente, com o uso de peles de animais roupas, como o uso de animais em testes de laboratório. Tudo isto é licito e importante porque abusar da natureza e de nossos companheiros animais. Mas da mesma forma não podemos abusar dos outros seres humanos. Não o fazemos diretamente  e por isso funciona para eles – os que ganham com isto.

Em vez de se preocupar com um problema “verde” que não existe e que foi desenhado para levar você a gastar mais dinheiro, preocupe-se com um problema real, documentado e existente de não ajudar a criar mais escravos e por mais crianças a trabalhar.

Sim, é possivel doar dinheiro para entidades que se ocupam com estas coisas, tal como é poissivel doar para organizações que se preocupam com o uso de animais para experiencias e vestuário e salvar as baleias. Mas as melhor forma de você ajudar tudo isto é consumir com consciência.

O ser humano consome por natureza é impossivel pará-lo de consumir. Mas consumir com responsabilidade não se limita a proteger os recuros naturais. Incluir em se responsabilizar por proteger vidas e valores morais numa sociedade cada vez mais globalizada. Cada vez menos importa a lingua, o pais e o seu credo e muito mais quais são so seus valores humanos. Esses são internacionalmente entendidos e aceites.

Protega o seu futuro e o de seus filhos e netos se procupando o mal que está fazendo ao mundo comprando produtos que são fabricados em condições precárias de um sub-mundo que só quer seu dinheiro custe a quem custar, desde que não seja a eles.

Se ha criminosos no mundo é apenas porque ha quem compre deles.

O Mito da Carreira Profissional

Para muitas pessoas ter um emprego estável é uma meta importante. Estável significa que não será despedido tão cedo e que seu salário tende a acompanhar as suas necessidade. Deste conceito nasce o conceito de Carreira Profissional em que a pessoa evolui dentro da empresa se um trabalho para outro. Para alcançar isto, a pessoas tem que trabalhar exclusivamente em uma só empresa e  isso leva ao conceito de que o trabalhador “pertence” à empresa.

O conceito de que o trabalhador “pertence” à empresa leva ao conceito de que se a empresa protege seus bens, então deve proteger seus trabalhadores. Especialmente deve manter os seus salários altos. Por outro lado, leva ao conceito de que a empresa é o conjunto dos seus trabalhadores. Tudo isto são ilusões.

Na realidade o trabalhador é livre para mudar de emprego para outra empresa a qualquer momento, e a empresa é livre de mudar de empregados a qualquer momento. Não existe vinculo exceto aquele condicionado pelo horário de trabalho que, na prática, causa um vinculo de exclusividade, embora na teoria a pessoa é livre de ter quantos trabalhos quiser.

O trabalho é um fator produtivo como qualquer outro. Se uma matéria prima escasseia a empresa irá antever formas de substituir essa matéria prima por outra. O mesmo se aumentar de preço. Se a matéria prima abunda o seu preço é menor porque a concorrência assim o força. O mesmo com o trabalho. Se ha muitos trabalhadores de uma certa especialidade a empresa contrata os mais baratos, se ha poucos, ela tem que competir pelos poucos que ha aumentando o salário. Claro que ao falar em salário me refiro inclusivamente a todos os benefícios que são pagos.

Não existe ponto de equilíbrio. É um processo cíclico constantemente em rotação.

Neste cenário não faz sentido pensar que a pessoa tem alguma chance de permanecer na mesma empresa por muito tempo. É simples. Quando ela acumular um valor que se equiparar ao do mercado ela será substituída. O truque, portanto, é nunca deixar que a massa do mercado chegue nos seus calcanhares. A pessoa tem que se manter acima da média, bem acima, para se manter na posição que ocupa. Por outro lado, em outra empresa, essa mesma posição pode pagar melhor ou ser de alguma forma mais vantajosa. E ai é tempo da pessoa mudar de empresa.

Da mesma forma que as empresas procuram constantemente revitalizar seu quadro, também os trabalhadores  precisam se mover entre as empresas. A idéia de que a pessoa entra no departamento de entregas e depois de um tempo acaba na presidência não advém de um mecanismo interno da empresa, mas sim da constante busca dessa pessoa em se destacar da massa que o rodeia.

Neste sentido, a Carreira Profissional é o conjunto de operações, estudos, e extensões que a pessoa adquire ao longo da vida que lhe permitem se manter acima da massa regular  e não o conjunto de cargos que ocupou numa mesma empresa.

É um erro entrar numa empresa e esperar ficar nela para sempre. Igualmente é um erro sair dela antes de aprender o suficiente. Do ponto de vista da empresa é um erro manter pessoas que não evoluem, mas igualmente é um erro não lhes dar espaço para evoluir.

Acho que a conclusão é : não existe segurança no emprego, então parta do principio que você vai mudar mais cedo ou mais tarde e não que vai ficar ai para sempre.

Uma nova edificação

Por esta hora – quase um mês depois do meu ultimo post – alguns podem estar pensando o que tenho andado a fazer.

Quando criei este blog lá em 2007 era para ser apenas um lugar onde pudesse escrever sobre os meus gostos – que são muitos e variados. O “problema“ é que rapidamente o gosto maior tomou conta: o Java.

Eu escolhi me especializar em Java, em tudo o que diz respeito a Java, por razões profissionais, mas se tornou um hobby muito interessante ao ponto de me fazer criar o MiddleHeaven. Através do Java aprendi sobre Orientação a Objetos e mesmo sem os purismos de Smalltak o estreito mapeamento entre a linguagem Java e os conceito de Orientação a Objetos concorrem para que quanto mais se conheça um, mais se aprecie o outro.

Hoje, o meu blog é visitado por milhares de pessoas todos os meses que procuram se educar um pouco mais nestas coisas e aprender a criar aplicações Java melhores, fugir de más práticas e aprender melhores formas de codificar e mapear o mundo real para objetos. Muitos defendem a visão empirista em que através de tentativa e erro se chega a um modelo bom e uma aplicação robusta. O experimentalista em mim  entende essa visão, mas o arquiteto em mim prefere ter menos trabalho criando um modelo mais duradouro. O desafio é grande, mas a recompensa será maior.

Só que, há um problema com esta visão. Os consumidores de software coorporativo, ao contrário dos consumidores caseiros, não sabem o que procurar em um software, não sabem avaliar a sua qualidade. E o pior é que nem os desenvolvedores sabem avaliar essa qualidade. Ela é intangível, imensurável. Contudo, ela não é subjetiva. Existe sim o bom e o mau. O Padrão e o Anti-Padrão, o crédito e o débito técnico.  O problema que eu vejo é que tanto desenvolvedores, quanto os donos de empresas que produzem software, quanto os consumidores desse software adoram gastar rios de dinheiro e ampulhetas de tempo em gambiarra, mas não dão o braço a torcer para procurar qualidade, diminuição de custo, mais-valia. A culpa do débito técnico sobre a recompensa do crédito técnico. Sentimento de utilidade para quem compra e sentimento de orgulho para quem vende.

É por isso que no ultimo mês coloquei na prática os alicerces de uma idéia que há muito estava na minha cabeça. São os primeiros tijolos para um espaço que levará as pessoas a produzir melhor software de forma mais barata, sem gambiarra, sem prejuízo para a saúde mental, emocional ou moral de ninguém e que os cliente sintam vontade de usar e evoluir.  Um portal que ajude a explicar o que é um produto software, como se faz e por que se faz assim. Tecnologias, Práticas, Regras, Teorias, Tutoriais e, espero, muitos exemplos rodando no seu navegador e no seu desktop que comprovem  que isto é possível e ajudem a enterrar as velhas práticas da Era da Pedra ( do cartão ? ) da produção de software como um bem.

Este empreendimento é maior que eu. É maior que um só blog. É necessário um lugar  com mais recuros e menos limitativo que estas fronteiras, onde esta ideia possa ser discutida, aperfeiçoada, exemplificada. É um novo edifício. Hoje ainda com poucos cômodos, mas que logo crescerá. O céu é o limite. A nova casa para o desenvolvimento de aplicações com Java: www.javabuilding.com

Java é o próximo C

Muita comoção tem rolado por ai sobre como a linguagem Java será substituída por outras, especialmente as linguagens que estão entrando na JVM.

Acho que muita gente não entendeu que o J em JVM significa Java. O que quero dizer com isto é que a JVM foi feita para correr Java. Ok, ela foi feita para correr Java Bytecode, mas no fim existe uma estreita relação entre a linguagem Java, o bytecode e a JVM.

Muitos dos avanços da plataforma desde a versão 1.5 vieram da generalidade do bytecode face à linguagem que por exemplo, aceita coisas como herança múltipla que a linguagem não aceita. Mas muitos outros vieram de truques de compilação em que o compilador aceita sintaxes diferentes e as compila para o mesmo bytecode de sempre.

As novas linguagens da JVM como Groovy e Scala desenvolveram compiladores que compilam para o mesmo bytecode mas devido à falta de alguns construtos na JVM estas linguagens precisam usar de alguma magia para que tudo funcione perfeitamente.

Pois bem, a solução óbvia é incrementar a JVM e o bytecode com novos construtos necessários a estas linguagens : invocação dinâmica, tail call, continuations, etc..

O ponto é que, devido à estreita relação entre a JVM e a linguagem Java , o Java tem a oportunidade de absorver estas novas capacidades. É claro que mesmo a JVM as tendo a linguagem não é obrigada a ter, mas não há razão para que não possa. Tudo parece se resumir a gostos políticos e a indecisão às interjeições que estão acontecendo com a venda da Sun à Oracle.

O futuro da JVM é bem claro. Ela tem que evoluir para suportar mais linguagens que Java. É o mesmo tipo de evolução da VM .NET cuja tecnologia não está nem perto da JVM mas suporta várias linguagens.

O futuro da linguagem Java pode não incluir modificações a curto prazo, mas não há razão para não o fazer e várias para fazer. A razão principal para as fazer é tornar a linguagem Java a como a linguagem base para JVM da mesma forma que o C é a base para as máquinas não-virtuais.  Da mesma forma que o Java e outras linguagens utilizam o C para comunicar com máquina real, linguagens na plataforma java utilizarão o Java para comunicar com a JVM.  Tudo isto de forma tão encapsulada quanto a comunicação do Java com a JVM.

O Java 7 pode conter um monte de pequenos acertos na linguagem escrita que se compilarão para o mesmo bytecode. Açucar sintático (sintax sugar) é como se chama a isto. Coisas como inferência de tipos genéricos em declarações ou acesso a listas como a sintaxe de arrays. Tudo isto interessante e desenhado para minimizar a escrita pelo programador. Contudo acertos no nivem baixo serão poucos. A invocação dinâmica que estará presente – ao que tudo indica – não será suficiente a longo prazo, mas já quebra o galho de muitas as linguagens da JVM como Groovy.

O precisamos entender é que Java sempre estará presente mesmo quando outras linguagens tomarem o pódio na JVM. Se, por exemplo, Scala, se tornar a linguagem mais utilizada sobre a JVM, ainda assim o pessoal que implementa,  e especialmente que estende essa linguagem, terá que o fazer usando Java. Java passa assim a ser a linguagem de baixo nível que a JVM aceita como par. É como a Common Language Runtime do .NET ou o C da programação para máquinas físicas. É o esperanto da JVM que todas as novas linguagens terão que saber falar.

Esta realidade não apenas significa que o Java não está morto, como o seu uso será cada vez mais especializado. Enquanto a maioria dos mortais usa Scala, Groovy , Fortress ou outra linguagem sobre a JVM, extensões serão feitas nessas linguagens por uma minoria programando em Java. Além disso novas linguagens serão criadas com Java sobre a JVM.

O uso do Java pelas massas poderá diminuir  tal como C diminuiu, e outras linguagens mais produtivas virão. Mas Java continuará lá sendo o C da JVM , sendo o C para das novas linguagens. Você poderá fugir de utilizar java no dia a dia, mas não poderá dizer que java morreu da mesma forma que hoje a JVM existe porque é construída com C.

Dito de outra forma, você pode escolher outra linguagem e abandonar a linguagem Java, mas não poderá fugir de usar a JVM e toda a plataforma que já existe.

Uma ótima apresentação pelo Niel Gafter chega , eu acho, nesta mesma conclusão.

Como epílogo podemos concluir que utilizar alguma plataforma fora JVM é um risco. As grandes apostas e os grandes apostadores  estão sobre o Java. Se a Oracle não pisar na bola, continuará assim. Do outro lado, temos cada um apostando no seu cavalo e isso não poderá chegar perto da evolução da JVM a curto prazo. Utilizar linguagens fora da JVM  é um risco e até linguagens como PHP , Pytohn e Ruby estão vindo para a JVM. É uma questão de tempo até que as funcionalidades dessas linguagem vazem para a linguagem Java.

E você acha que é programador?

Escrever software implica comunicar a uma máquina as intenções de um ser humano. Para qualquer comunicação é necessário um conjunto de símbolos que ambas as partes reconhecem e entendem. O problema com as máquinas de hoje é que elas entendem um número limitado de símbolos, muito menor que o dos humanos.

Para resolver isso, vários paradigmas foram criados buscando transmitir à máquina as intenções do ser humano. O mais vantajoso até hoje é o paradigma da linguagem de programação.

Programar significa utilizar uma certa linguagem para transmitir uma série de instruções ao computador. O ser humano escreve com símbolos que ele entende – palavras e símbolos textuais – e isso é transformado para o símbolos que a máquina entende através de um programa chamado compilador. Sim, você pensou certo. Se o compilador é um software, e um software é criado com um compilador, como se criou o primeiro compilador?

Parece uma charada mas não é. Acontece que existem diferentes níveis de linguagem. Linguagens de alto nível e de nível máquina ( “baixo nível” não se diz porque é feio). Os primeiros compiladores eram escritos em linguagens de nível máquina com os quais se criaram compiladores de nível mais alto e assim sucessivamente até linguagens de alto nivel como Java, C++ ou C#. O paradigma orientado a objetos é atualmente o paradigma das linguagens mais flexível e difundido, já que nele é possivel montar linguagens com outros paradigmas (procedural, funcional, etc) sem perda de generalidade.

Bom, temos uma linguagem. Toda a linguagem escrita tem um semântica e uma sintaxe. As de programação também têm. E toda a escrita é redigida por alguém.  No mundo editorial quem escreve é redator, mas no mundo do software, quem escreve para máquinas é programador. O texto que o programador escreve é chamado “código” (alguns chamam de código fonte, do inglês “source code“) para transmitir a ideia que é meio críptico e muito “secreto”.

Mas então qualquer um que escreve código é um programador? Tecnicamente sim, mas na realidade isso não diz muito sobre o que a pessoa faz ou sabe fazer. É como dizer que todos os autores de best sellers sabem escrever. Isso é verdade, mas não significa nada de útil. É uma tautologia se pensarmos bem.

O que é interessante para o mundo do software não é que a pessoa saiba escreve código,  o interessante é que a pessoa escreva bom código. Da mesma forma que autores escrevem bons livros. Para isso é preciso uma capacidade técnica maior que simplesmente escrever palavras. O programador é para o código o que um autor é para um livro e não apenas um redator. Bom, pelo menos um (bom) programador aspira a ser um autor e não um redator.

Da mesma forma que na língua portuguesa também nas linguagens de programação uma instrução pode ser escrita de várias formas. Umas mais claras que outras. E enquanto qualquer frase minimamente representativa da ideia basta para a pessoa comum, não basta para o autor que quer tirar o maior partido das palavras que pode usar para escrever em menos espaço o maior número de ideias. Mas também existe um limite. Ser conciso demais pode levar à confusão do leitor médio. Um autor não escreve para si, escreve para  os demais, para ser lido, já que o objetivo ultimo é vender livros difundir as suas ideias.

O programador sofre do mesmo problema. A linguagem até pode permitir que ele escreva mais em menos palavras, mas nem sempre isso é a melhor forma para quem lê. A variedade C de linguagens é conhecida por permitir uma ampla gama de formas de escrita – bastante crípticas, por sinal. E Java permite que tudo seja escrito usando códigos Unicode como \u0002 … Lá porque você escreve dessa forma, não significa que o deva. Essa é a diferença entre um autor e um redator. Essa é a diferença entre um escritor de código e um programador.

Mas saber escrever não é apenas colocar palavras juntas. Existe mais. Existe conhecer as palavras em si mesmas, as regras da linguagem (como escrever corretamente) e  conhecer a semântica da linguagem (o que as palavras significam). Para programadores isso significa saber o que cada palavra reservada faz, assim como as bibliotecas padrão que acompanham a linguagem.  Estas bibliotecas são como dicionários de palavras novas que podem ser (re)utilizadas a cada momento para enriquecer o texto.

Muitas linguagens, poucas palavras

Quando você aprende a falar e a escrever, normalmente, você aprende a língua de seus educadores, que por extensão é a língua do seu país. A sua língua natural. Também quando você programa você começa por aprender uma linguagem. A diferença é que essa, ainda não é, a sua linguagem natural.

Durante a vida do programador ele aprende muitas linguagens da mesma forma que aprendemos muita línguas. Afinal, traduções são limitadas, em si mesmas, na riqueza de transmitir o pensamento (as instruções) do autor, e ler o original, na lingua originalmente pensada para transmitir a mensagem, é sempre uma experiência mais rica. O programador passa por um tempo de busca da sua linguagem natural. Aquela que ele entende e é proficiente sem esforço. Imagine um prêmio nobel da literatura escrevendo em outra língua que não a sua.  Não é simples atingir o mesmo nível de intimidade com todas a linguagens. O programador descobre isso com o tempo.

Pensemos que você decide aprender todas as línguas faladas na Europa. Parece simples. Você até é capaz de agradecer e perguntar as horas em todas elas, mas você consegue manter uma conversa longa em todas elas. sem parecer um idiota?

Parecer um nativo é impossível. Você tem que ser um nativo para falar e escrever nativamente.  É um erro a pessoa pensar que pode aprender uma lingua/gem por tradução daquela que já conhece. Isso dá para o básico, não para o avançado, muito menos para o extraordinário.

Assim, quantas mais linguagens, menos palavras. Em termos de software, você pode conhecer muitas linguagens e fazer o básico em todas elas, mas só será proficiente em algumas e só será intimo com uma ou duas. É uma regra natural, seu cérebro não aguenta saber tudo todo o tempo.

O programador tem então três caminhos. Ser um autor memorável em uma linguagem, ser um “zé-ninguém” em todas ou ser um “meia-boca” em meia dúzia.

Profissionalmente você não ganhará bom dinheiro sendo autor memorável em uma linguagem nem “zé-ninguém” em todas. Você ganhará dinheiro sendo proeficiente em uma ou duas e se desenvolver com uma ou duas (o que é desenvolver é assunto para outro post). Ou seja, você acaba deixando de ser autor no meio do caminho para passar a ser editor, revisor,  professor ou dono de uma editora. É uma mudança de carreira, mas uma necessária nos dias de hoje (um pequeno segredo: ninguém quer realmente pagar para alguém escrever código bem. O mercado, hoje, está preocupado em escrever depressa. Não bem.)

O programador pode evoluir em amplitude ou em profundidade, mas não em ambos. É demasiado extenuante. O “problema” é que para evoluir ele precisa aprender pelo menos uma linguagem em profundidade.

Bom, então se o caminho profissional natural do programador é deixar de ser programador,  se ele se dispersa em várias linguagens, nunca será ninguem no mundo do software ?  Sim. Se você ficar perseguindo linguagens novas todos os dias acabará acordando – tarde – para o fato que não está em lugar algum. Como o andarilho que percorre e conhece todos os caminhos, mas  não onde voltar depois da caminhada. Pelo contrário, se você seguir uma ou duas linguagens, você atingirá o nível necessário para passar ao próximo nivel: desenvolvedor.

Não há vergonha nenhuma em você ser um bom programador em duas linguagens e excelente em uma delas.  Aliás, deveria se sentir dignificado com isso, já que é raro.  Mas é como o cara que saber fazer contas de cabeça com 1000 algarismos e de trás para frente: assombroso, mas ninguém pagará você para fazer isso. (Bom, quase ninguém. Se você for louco talentoso o suficiente para fazer isso, alguem pagará.)

Quando uma pessoa é inciada no mundo do software espera-se que saiba programar. O famoso “programador júnior”. O que ele sabe é escrever código. Não programar. Porque normalmente ele não entende o que escreve e não escreve coisa intelegível. Mesmo que funcione, ele não sabe por onde começar na hora de alterar ou re-escrever em outro lugar. É natural. Afinal todos tivemos que saber o alfabeto antes de saber escrever o nosso nome. O problema é que com tantas linguagens por aí é fácil a pessoa se frustrar e constantemente mudar de rumo. Saberá muitas linguagens, mas saberá dizer pouco.

Se você se apresenta como programador,  pergunte-se: eu sei realmente escrever bem? Os outros entendem meu código sem eu explicar? Estou seguindo as regras? Sei escolher as instruções e API certas ?

Sem saber , você pode ser um “zé-ninguém” em todas as linguagens ou um “meia-boca” na meia duzia com que se cruzou até hoje. E você, ainda, acha que é programador?

De Sênior a Gerente

Se você é desenvolvedor a algum tempo com certeza já se deparou com a questão da promoção de sênior a gerente. Por algumas razões que iremos analisar as pessoas não só aceitam este fato como esperam por ele.

Não é incomum durante uma entrevista perguntar para o candidato a uma vaga de desenvolvedor onde ele se vê daqui a 5 – 10 anos, e a resposta costuma ser “como gerente”. A razão para isso é simples: dinheiro. Historicamente a pessoa na posição de Gerente ganha mais que a pessoa na posição de desenvolvedor, seja qual for a sua classificação ou maturidade. Mas esse, espante-se, não é o único fator. A chamada da sereia do poder é prazerosa.

As empresas acham que promover a pessoa de desenvolvedor sênior para gerente é uma coisa boa. Não é. E as pessoas na sua extrema visão curta só enxergam essa opção.  Não é segredo que todos queremos ganhar mais, então quando a pessoa diz que quer ser gerente o que ele está dizendo, na verdade, é que quer mais dinheiro. Nesse ponto eu desclassifico o candidato já que ele ainda não deixou de ser júnior e já quer ficar mandando nos outros.

Por razões que o tempo conhece as empresas se habituaram a pensar que criar software é dificil e que a probabilidade do projeto de software dar errado é grande. Portanto, os diretores que não querem ver o seu na reta adotam a política de: 1) por um lado criar bodes expiatórios na pessoa do gerente. Se o projeto der errado eles serão culpabilizados e o diretor manterá o seu emprego; 2) é preciso microcontrolar tudo o que os desenvolvedores fazem para que assim não existam imprevistos e não existam atrasos.

O curioso é que são exatamente essas medidas de “contingência” que fazem o projeto atrasar.

O resultado é que em uma hierarquia de um diretor de produção de software é comum existirem vários “gerentes”, os quais tentam microcontrolar a equipe de desenvolvimento. A pessoa no papel de gerente  rapidamente  sacrifica os membros  da equipe para manter um salário um pouco melhor que eles sendo que ele seria incapaz de realizar o mesmo trabalho. A imagem do feitor de escravos me vem à mente.  O pior de tudo nem sequer é isso. O pior de tudo é que, normalmente, a pessoa na posição de gerente não tem capacidade técnica nem política para desempenhar esse papel. Sim, a pessoa foi desenvolvedor sênior 20 anos atrás. Isso não lhe dá conhecimento nenhum sobre como o software é feito hoje.  Não apenas a linguagem e o paradigma utilizado hoje são diferentes, como também as técnicas e ferramentas em volta (uso de repositório de código, por exemplo). Quanto mais cedo a pessoa passou de sênior a gerente mais óbvio é este fato, no limite absurdo de comparar, por exemplo, a plataforma Java com linguagens como Clipper, Delphi ou VisualBasic. Você já reparou como o seu gerente reduz tudo a operações no banco de dados e desconhece o conceito de “Servidor de Aplicação” ou o confunde com “servidor web” ?

Quanto à parte política, a pessoa na posição de gerente não tem qualquer escruplo ou vergonha em pedir ao desenvolvedor para trabalhar extra para manter o (famoso) cronograma. Mas  peraí! Não é o gerente que criou o cronograma? Se houver atraso não é responsabilidade dele? Infelizmente no mundo atual não. Nada nunca é responsabilidade do gerente e ele faz de tudo para que assim não seja. O clássico é pedir que os desenvolvedores estimem o cronograma. Ele pede que “estimem” mas o que ele quer dizer é “assinem com sangue um chute de quanto tempo vai ser necessário”. Depois o gerente faz a seguinte conta: se a “estimativa” é X então como temos N desenvolvedores vai demorar X/N tempo. A estimativa … quer dizer, a corda no pescoço da equipe de escra… desenvolvedores ficou ainda mais apertada. Nestas condições totalmente indecentes a equipa tem zero motivação , zero ajuda, zero autoridade, total responsabilidade e lá para quando faltarem dois meses para o final do prazo do cronograma fajuto a equipa ainda passa a ser chicoteada diariamente com a pergunta “Quantos porcento falta para estar pronto?”. O que revela que a pessoa no lugar de gerente não sabe o estado das coisas, ou seja, ela esteve fazendo o quê enquanto os desenvolvedores criavam o software? Esperaria-se que estivesse exatamente calculando quanto tempo falta. Certo ?

O diretor (a pessoa hierarquicamente acima do gerente e que o contratou como bode expiatório profissional) não se preocupa com a performance do gerente. Apenas com a da equipe. Afinal todos os males advém da equipe de desenvolvedores. Esses seres abjetos que o diretor é obrigado a tolerar para poder vender alguma coisa a alguém. Ao diretor tanto lhe faz se o gerente explora os desenvolvedores da mesma forma que o senhor lhe importa um pepino que o feitor chicoteie os seus escravos. Não só isso, como o diretor espera que o gerente aja assim.  Tanto isso é verdade que em empresas maiores (leia-se “com mais níveis de isolamento dos seres abjetos da equipe”) existem uma camada de gerentes. O diretor delega para N gerentes, cada um deles delega para M outros gerentes, que delegam a outros … em um cadeia até que se chega no gerente que controla a equipe. Vejam bem o estado da coisa. O gerente não serve para gerenciar o projeto. Não. Isso é fácil, qualquer excel ou project pode fazer isso. O gerente serve para controlar a equipe em uma mistura de babysiter com capataz e a empresa é tanto maior quanto mais gerentes forem controlados por outros gerentes.

Quantos “gerentes” estão acima de si na sua empresa? Dito de outra forma, quantas pessoas podem vir chateá-lo na sua mesa com exigências para ontem ?

Parece então óbvio porque um desenvolvedor quer virar gerente: 1) mais dinheiro no fim do mês; 2) menor ou nenhuma responsabilidade sobre o projeto ou o software; 3) direitos de fustigar a equipe como e quanto quiser; 4) receber todos os louros dos superiores quando o projeto dá certo; e 5) nunca ser “castigado” por nada.

Parece muito melhor que a vida de um desenvolvedor que 1) ganha pouco para aquilo que faz e a responsabilidade que tem; 2) tem toda a responsabilidade sobre o resultado mas nenhum autoridade para guiar o processo; 3) é interrompido a todo o momento com perguntas idiotas que não são da sua responsabilidade responder como “Quantos porcento do projeto já está completo?” 4) nunca recebe o agradecimento real de ninguém nem o reconhecimento real do esforço (eu disse real e não aquele tapinha nas costas ou aquele e-mail de agradecimento modelo B) e 5) é sempre “castigado” por tudo no limite de ser despedido por justa causa por erros cometidos pelo gerente, pelo diretor ou até pelo erro estratégico da empresa como um todo.

Se você teve estômago para ler até aqui, parabéns. Vejamos agora um pouco do outro lado. Afinal, nem todo o mundo é mentecapto e alguma pessoas querem realmente ganhar dinheiro a sério e não apenas para pagar as contas. Qualquer economista, por muito ruim que seja, sabe que uma forma de ganhar mais é gastar menos. É fácil gastar menos com desenvolvimento de software.

Primeiro, foque no que dá dinheiro. No caso do software o que dá dinheiro é o software, funcional e entregue. Muito importante o entregue. Segundo, desenvolvedores são pessoas com educação superior e qualificadas a resolver problemas lógicos e matemáticos complexos. Não os trate como animais de curral. Converse com eles e ouça o que eles dizem. Melhor que ninguém eles sabem quais são os problemas com o software. E ninguém melhor que ele sabe como traduzir o que é esperado pelo mercado em código. Eles podem ajudá-lo não apenas a resolver problemas técnicos mas até problemas que impactaram na venda do software ou na aceitação pelo público. O seu foco é fazer software, então dê recursos aos desenvolvedores para o fazerem. O foco da empresa é o software e todos devem ajudar a conseguir que ele seja feito nas melhores condições de mercado possíveis.  Simplifique os processos. Coloque no lixo a hierarquia militar de passar ordens entre níveis.  Muita informação se perde dessa forma quando o assunto é complexo como um software. Pode até funcionar para a guerra onde as ordens são simples, mas não numa empresa de software.  Uma muito boa forma de conseguir isto com facilidade, sem gastar dinheiro e com um retorno imediato é substituir todos os que se dizem gerentes por desenvolvedores sênior (realmente sênior e não apenas júniors disfarçados). Implementar Scrum também não é má ideia, mas se você tem um outro processo que realmente funciona para a sua empresa (eu disse, realmente - o que significa que todo o mundo na empresa acha que funciona) então mantenha esse.

Implemente um mecanismo de carreira. Não separe os desenvolvedores por anos de trabalho  e sim preveja que todos têm mais do que uma habilidade. Não é desmérito para ninguém só saber programar bem. Saber escrever código limpo, bem estruturado, que aproveita ao máximo as funcionalidades da linguagem não é pecado. Nem todos têm  de ser arquitetos. Não é desmérito para ninguém ser um bom tester que sabe escrever testes automáticos com boa cobertura.

A vida de um desenvolvedor têm várias partes e não são: júnior , sênior, gerente. São: programador, engenheiro,  tester, designer, analista e arquiteto. E isto não é uma sequência. Cada um pode ser mais do que uma coisa. Aliás tem que ser mais do que uma. Existe o básico que é ser programador (saber programar não é suficiente) e existe o complexo: analise é uma tarefa ao mesmo tempo técnica, interpessoal e até política onde poucos engenheiros e arquitetos se sentem bem. Moral da história, monte uma equipe multidisciplinar sem gerentes fustigadores mas com pessoas que ajudem a resolver os problemas políticos, burocráticos e administrativos e deixe o desenvolvimento com quem entende.

A próxima década não terá pena de quem não se ajustar à nova ordem. Quem ainda quiser ficar fuçando no código como se fazia à 20 ou 30 anos atrás não vai chegar a lado nenhum diferente da falência. A concorrência é maior que nunca e o mercado de tecnologia é maior do que nunca. Quem não primar pela qualidade não vai vingar.

A escravatura das fábricas de software tem que acabar. O primeiro passo é que você, desenvolvedor,  não aceite esses termos.  Aspire a ter capacidades de análise, conhecimento de arquitetura, design ou teste, e não a ser um gerente mentecapto e escravocrata.  Afinal, você gostaria que pensassem de si o que você pensa do seu gerente?

De Júnior a Sênior

Vivemos uma época transformadora no desenvolvimento de software . A partir da segunda década do século XXI só vai sobreviver quem fizer software barato (leia-se: sem “gordura”),  recheado de valor, feito com responsabilidade e entregue no prazo. É a hora de separar o trigo do joio.

Os sufixos júnior e sênior me aborrecem enormemente desde sempre. Especialmente quando utilizados fora de contexto ou como sinônimos de “tempo de serviço”. Mas o que realmente faz de você um júnior ou um sênior?

A resposta a esta pergunta pode não ser o que você esperava ouvir. Mas se quiser trabalhar com software nos próximos decênios é bom que a aceite.

A diferença entre júnior e sênior não está na idade, nem no tempo de serviço. Está na maturidade técnica e na maturidade profissional.

Para um júnior, trabalhar muito é sinônimo de “bom”. Trabalhar até altas horas e acumular um monte de horas extra é um sinal de dignidade. Para um sênior só de isso ser sugerido, é um insulto. O sênior sabe que se algo der errado não é com horas a mais ou fins de semana longe da família que o problema se resolve. Bem pelo contrário. Se agrava. Então a posição do sênior é não ter problemas. Para isso ele usa todos os seus skills técnicos para que problemas não aconteçam ou sejam facilmente mitigados. Um bom design, uma bateria de testes automatizados e muito refactoring são ferramentas básicas do sênior para não deixar “a vaca ir p’ro brejo”.

Para um júnior, boas práticas são subjetivas e discutíveis e gambiarra é um martelinho de ouro que resolve todos os problemas com uma pancada só. Para o sênior, as boas práticas são como leis da natureza, objetivas e irrevogáveis, e a gambiarra um pecado demoniaco intolerável que tem ser exorcizado a qualquer custo de todo aquele de quem se apodera. O sênior sabe que seguir bons princípios e boas práticas fazem as coisas fluirem mais facilmente e responder mais eficazmente a imprevistos enquanto o júnior ignora que as suas gambiarras são aquilo que está fazendo seus fins de semana serem perdidos na empresa ao invés de poder estar em casa ou em passeio com os amigos ou a namorada.

O júnior acha que o objetivo de construir um software é fazer o programa funcionar. O sênior sabe que o objetivo de criar um software é fazer uma aplicação de fácil manutenção. Pois é na manutenção que está o custo e não na criação.

O júnior acha que com 3 anos de serviço pode ser um pleno. Um pleno tapado será se pensa que o tempo traz experiencia. O trabalho é que traz experiencia. O sênior sabe que desenvolver software é uma arte e uma arte não se aprende com o tempo e sim com a prática.

O júnior tende a usar pouco a cabeça, tentando seguir ao máximo “receitas de bolo”, sem se ater ao contexto. O sênior racionaliza o problema e encontra a solução mais flexível até à solução. Normalmente esta solução só é possível com o uso de alguma técnica avançada de desenvolvimento de software como o uso de  objetos  em vez de rotinas. Como para o júnior boas práticas são piadas que se contam aos amigos este tipo de técnica passa longe.

O júnior fica feliz quando o dinheiro entra na conta todo o mês, o sênior dorme tranquilo quando sabe que o código que a sua equipe fez tem qualidade e pode ser mostrado a qualquer um.  Bom, nisso o junior é muito semelhante. Ele também não tem nenhuma vergonha do código que escreve. Acontece apenas que ele não a tem porque não enxerga as tremendas burrices que o seu código exclama.

Maturidade profissional não se ganha com o tempo. É preciso que a pessoa tenha orgulho no que faz e prime pela qualidade do que faz. Só isso a fará se aprefeiçoar.

Se você acha que ainda é júnior, não se desespere, aprimore-se. Acredite que as boas práticas são realmente boas e apreenda-as. Use-as. Tenha orgulho do que faz e vergonha dos seus erros. Procure qualidade e não quantidade. Procure terminar antes do prazo e com mais funcionalidades e não se faça de preguiçoso para poder arrecadar algumas horas extra. Seja profissional. Desconfie de qualquer um que o tentar levar pelo mau caminho.

Se você conhece alguém nas condições descritas aqui como júnior que ocupa um cargo sênior não tenha medo nem vergonha em o desafiar. Tanto tecnica como profissionalmente. Teste-o. Ele pode estar enganando você. E se você é diretor de gerentes de TI, a probabilidade de estar sendo enganado por um júnior se passando por gerente é quadriplicada. Cuidado, abra os olhos.

Se você é um sênior, tal como descrito aqui, meus parabéns. Agora é hora de elevar a qualidade exigindo mais dos que estão à sua volta. Ou dobra ou parte. Não há meio termo. O seculo XXI não terá pena de quem for conivente com a mediocridade.

Sistema pequeno. Mente pequena ?

Existe uma moda de falar em sistema pequenos. “Posso fazer xxxxx ? é para um sistema pequeno.” , ” se eu fizer xxxxx tudo bem, certo? é apenas um sistema pequeno” – todos já ouvimos isto e até alguns já podem ter dito. Normalmente xxxxx é alguma gambiarra.Do tipo, posso fazer meu sistema apenas com métodos estáticos ? é um sistema pequeno.

Para mim isto é uma falácia do pensamento. Não existe sistema pequeno. O sistema pode nascer pequeno – modesto em funcionalidades – mas ele tende a evoluir. Mais cedo ou mais tarde esse sistema irá precisa de manutenção (leia-se corrigir algum problema ou aumentar as suas funcionalidades). Com a manutenção o sistema irá crescer.

Esta lógica leva-me a crer que quando alguem diz “sistema pequeno” está pensando em “sistema fast-food para enganar trouxa”, ou seja, “vou fazer esta porcaria, vender por uma nota e ganhar uma nota. Se o cara me processar depois, eu não vou estar mais aqui”. Este tipo de pensamento é triste. Mostra que ha muitos mercenários por ai que não têm qualquer honra no trabalho que fazem e tudo o que querem é dinheiro. Software, infelizmente, não dá dinheiro. Boas ideias dão dinheiro. Boas execuções dão dinheiro.

Será então que quem pensa em sistemas pequenos tem a vista curta ? Que não pensa a longo prazo ?  Este tipo pensamento pode-nos levar por um longo caminho de asneiras. Por exemplo, se o sistema é “pequeno” porquê construir camadas ? porque isolar componentes ? porquê escolher frameworks e tecnologias que trabalham bem juntas? porquê seguir boas práticas ? aliás, porquê aprender boas práticas ? porque investir aprendendo Orientação a Objetos ? porquê levantar requisitos ? porquê sequer fazer direito quando pode fazer rápido ?

Uma outra face desta moeda furada é o comum “vamos fazer só assim, e depois a gente vê como faz o resto”. Basicamente, traduzindo, significa “vamos fazer um sistema ‘pequeno’ e depois o aumentaremos”. Mas o que é pequeno aqui é a visão. Visão curta. Pensar grande corta tempo e custos porque se pensa em todas a partes. Não ha imprevisto nem surpresas. Podemos componentizar as coisas e deixar alguns componentes com implementações mais simples do que gostaríamos – mais simples, não mais “pequena”.

Aliado ao tamanho “pequeno” temos o intervalo de tempo “pequeno”. Frases como “vamos fazer um sistema pequeno para vender logo” ; leia-se : “vamos produzir um porcaria qualquer só para por no mercado sem pensar como isso afeta a nossa imagem , aumenta o risco e produz custos não estimados e altos”.

Os Romanos pensaram grande quando disseram “vamos conquistar o mundo”. E para isso criaram um estrutura social completa, infraestrutura. Infraestrutura sem a qual não seria possível conquistar nada nem ninguém. Criaram estratégias pontuais para alcançarem o objetivo maior.

Não pense pequeno. Aprenda a pensar grande. Aprenda a dividir para conquistar. Para isso nunca abra mão da qualidade do software que produz. É o seu nome, a sua dignidade, a sua honra que está nisso. Eleve a qualidade do código/software que lhe chega em mãos. Não tenha medo se defender a bandeira da qualidade. Se alguem não gostar, tenha a certeza que são eles que estão errados.

E sei que temos que comer e para isso precisamos trabalhar. E para trabalhar precisamos engolir alguns sapos de vez em quando. Mas existe um limite moral até onde você pode ir. A partir daí é trabalho intelectual forçado, é escravatura intelectual, é prostituição intelectual.

Mercenários pensam pequeno e ganham dinheiro, mas são infelizes e mal vistos pela sua falta de moral. Ninguém confia neles.  Artistas pensam grande e são normalmente felizes e as pessoas tendem a confiar neles.  Tudo bem que ha artistas que nada ganham e outros que ganham muito. Isso depende do talento de cada um. Não apenas do talento artístico como do comercial, interpessoal, etc..

Embora possa parecer que pensar pequeno pode ser uma vantagem a curto prazo, nunca é uma vantagem a longo prazo. E sendo que sistemas sempre duram além da sua vida útil, o longo prazo mal planejado tende a ser um problema.

Você pode pensar grande e dar passos simples , um de cada vez e chegar no que pensou. Mas ao pensar pequeno por muito que corra nunca vai chegar onde deveria. Isso porque você não sabe onde deveria chegar. Porque não pensou nisso antes ?

Nosso novo blog

Já era hora, eu achei, de criar um novo blog para falar do MiddleHeaven.

Tenho dedicado meu muito escasso tempo livre a este projeto durantes os últimos anos e está na hora de o mostrar ao mundo (e ser criticado por isso …).

O blog em inglês não deslanchou e o site feito pelo maven é pesado para atualizar. A ideias são muito mais fluidas e, contando que a minha equipe jornalística sou eu mesmo é bem mais facil utilizar um blog. A volta ao blog do WordPress em deterimento do Blogstop é que o Wrodpress apresenta a muito útil capacidade de criar páginas estáticas além do blog.

Convido a todos a conhecerem o nosso novo blog para entender e desenvolver o MiddleHeaven.

A seu tempo vou colocar nele os textos já apresentados, em inglês, no blog antigo.
Espero que acabe havendo algum cross-siting entre os dois blogs especialmente em referências a padrões e coisas relacionadas ao Java em si. Isso não era possível com o blog antigo devido à diferença da língua. Espero que isso, também, seja uma vantagem.

Aproveito para informar o estado do projeto. Embora já seja possível criar telas swing e sites jsp ainda falta um pouco para que as peças principais estejam no lugar.  Recentemente integrei o NeoDatis e parece bastante promissor, contudo, leva a uma revisao do modelo de dominio baseado em anotações (sem ORM , não ha necessidade das anotações). Por outro lado, revisei o mecanismo de wiring (injeção automática) para ser possível encontrar pontos de injeção por outras vias que não annotações. Desta forma é possível análises mais dinâmicas. O mecanismo de persistência é o próximo a ser revisto. Espero que após isso uma versão do framework possa ser usada para aplicações web simples (a la Spring / Struts / Vraptor / Mentawai) .

Claro que, para isso, você precisa estar preparado para não usar o Hibernate… será que aguenta ?