Em um dos dias do passeio, resolvi jantar com a minha esposa e um casal de amigos numa pizzaria famosa da região. A pizzaria era bem indicada, tem um website bem legal e tudo que tem direito. Com uma estrutura linda, uma faixada de dar inveja, toda em madeira, com um lugar bem estilizado e com direito a música ao vivo. Para minha surpresa, a pizza não era a das melhores. Eu até sai satisfeito, mas a minha esposa não gostou e acabou nem comendo tudo. De fato a pizza não era tão boa.

No dia seguinte, saímos novamente para comer a noite, mas dessa vez tinha que ser algo rápido, pois era necessário dormir cedo devido ao voo ser as 5 da manhã do dia seguinte. Perguntamos ao recepcionista da pousada se havia algum lugar por perto onde tinha lanche e ele nos indicou comer uma Pizza (novamente ?!?) ali bem próximo, no quarteirão seguinte. Ele também disse que os donos da pousada eram frequentadores. Depois que ele nos explicou onde ficava a pizzaria, saímos a pé mesmo pois era muito perto. Chegando em frente ao local, percebemos ser um lugar bem simples, ao ponto de nos fazer pensar se era aquele realmente o lugar que os donos da pousada frequentavam. Para ter uma idéia, nem lembro de como era a fachada/letreiro/etc. O recepcionista do hotel havia dito que esse lugar servia apenas pizzas individuais (um pouco maior que uma pizza brotinho) e confirmamos isso, tenho assim certeza que estávamos no lugar certo. Olhei o cardápio e vi que tudo era bem barato. Fizemos o pedido e aguardamos. A pizza era simplesmente muito gostosa. Muito mesmo. Em poucos lugares eu comi uma pizza tão gostosa por um preço tão barato. E olha que não é questão de custo/benefício. Se a pizza fosse mais cara que na outra pizzaria eu pagaria certamente, mesmo sendo uma pizza menor. Saímos dali muito satisfeitos e entendi o motivo que fazia os donos da pousada frequentarem aquele local. Por sinal, nem lembro o nome do lugar, mas lembro exatamente onde fica e se eu voltar algum dia a Natal certamente irei nessa pizzaria. E o que raios essa pizza tem a ver com experiência do usuário?

Essa minha passagem pelas pizzarias não foi premeditada, simplesmente aconteceu. Como cliente (ou usuário se você preferir), fiquei mais satisfeito com a pizzaria mais simples do que com a pizzaria mais bonita, requintada, que tinha website e tudo mais. E por que eu gostei da mais simples? Será que é por que eu não gosto de coisas requintadas? Claro que não. Eu gostei do lugar simples porque eles me serviram uma pizza melhor. O mais importante de uma pizzaria é a pizza ser gostosa ora bolas. Não adianta ter uma cadeira linda, usar um iPad pra fazer pedidos, guardanapo imperial e talher de outro se a pizza não for saborosa. É simples assim. E o que isso tem a ver com a nossa área?

Vamos pensar nas aplicações que fazemos no dia a dia. O Youtube, por exemplo, tem um site bem simples. Não considero o site deles uma obra de arte, muito pelo contrário. O player de vídeos deles provavelmente é um dos mais simples e feios que existem na web. Então por que será que ele é um produto de sucesso? Simples: o youtube da muita importância para o que tem realmente valor para o usuário do site deles, que é ver e compartilhar vídeos. É muito simples enviar um vídeo e mais simples ainda ver videos. Qualquer leigo consegue fazer isso. O player de vídeos deles funciona perfeitamente bem, apesar de não ter uma aparência linda. E o usuário se importa com essa aparência não muito bonita? Alguma vez você pensou em deixar de acessar o Youtube porque o site não é lá tão bonito? Acredito que não. Eu poderia citar diversos exemplos de produtos de sucesso que são extremamente simples e as vezes feios mas que são sucesso exatamente por focarem na necessidade do usuário, mas nem preciso citar porque acho que já deu pra entender onde eu quero chegar.

Parece chover no molhado, mas é impressionante o número de vezes que me pego discutindo ou observando discussões sobre se um site/aplicação precisa de borda arredondada, gradiente, se o cinza está um pouco mais claro ou escuro, ou se o botão está 1 píxel pra direita ou pra baixo, quando por vezes o que tem mais valor para o usuário nem está ótimo ainda. Não que esses detalhes não tenham importância, muito pelo contrário. O ponto aqui é que o foco deve estar primeiro no core business e depois nos acessórios. É o exemplo da pizzaria. Me lixei pra decoração linda, música ao vivo e requinte da primeira pizzaria, pois a pizza não era tão boa (se fosse certamente eu voltaria). Ao meu ver eles se preocuparam demais com coisas secundárias e esqueceram de contratar ótimos pizzaiolos. Certamente me lembrarei muito mais da segunda pizzaria, que era um lugar bem mais simples mas tinha uma deliciosa pizza.

Pra finalizar, pense um pouco sobre os motivos que fazem do iPhone um produto de sucesso. Provavelmente você perceberá que um dos menos relevantes é a sua beleza.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

No início

Em meados de 1997/1998, pouco antes da bolha da internet, quando eu comecei a trabalhar profissionalmente, eu trabalhava com eletrônica e informática em uma empresa de automação de ponto e acesso. Tive a oportunidade de usar Delphi para desenvolver um protótipo de sistema integrado ao hardware de ponto e acesso dessa empresa, pois eles usavam um programas DOS para extrair dados e jogar num arquivo texto, e o outro programa DOS fazia a leitura desse arquivo para gerar o resuldado de ponto e o acesso. Foi uma experiência ótima, pois meu protótipo acessava diretamente o equipamento pela porta serial e já mostrava as informações em tempo real. Essa idéia foi pouco tempo depois usada pela fábrica para novas versões do software.

Nessa época, a programação desktop ainda reinava e as opções mais comuns eram Delphi e Visual Basic, então sempre algum colega ou outro puxava a sardinha pro lado do Delphi ou do VB. Nessa época, confesso que eu era meio bobo no assunto e eu acabava entrando na onda também, principalmente falando mau do coitado do VB. Tempos depois acabei trabalhando com VB em outros lugares e pude perceber que existia aplicação para ele dependendo do caso. Confesso que sempre gostei mais do Delphi, mas nesse momento eu deixava de ser um apaixonado e passava a fazer a escolha de forma mais racional.

Surge o desenvolvimento pra Web

Quando começei a trabalhar com web em meados de 2000, trabalhei com PERL, depois ASP e ColdFusion. Nesse tempo, surgiu a versão Beta do DotNET em 2001. Foi quando comecei a desenvolver aplicações desktop em WindowsForms e alguma coisa web, com o objetivo de aprender.

Passado pouco tempo e fui trabalhar numa empresa onde usavam tudo da Microsoft. Java nem pensar nessa empresa. Todos falavam mau da Sun e do Java. Nessa época eu já estava bem escaldado com isso e não ia cair nessa novamente, perdendo meu tempo discutindo sobre quem era melhor, Java ou DotNET.

Passado mais um tempo, fui para uma outra empresa onde tinha projetos em DotNET, mas também tinha projetos Java. Como eu já estava estudando Java fazia um tempo, era uma ótima oportunidade para por em prática em algum projeto. Assim que surgiu uma vaga, me ofereci para entrar num projeto de um grande ecommerce brasileiro (que por algumas questões não posso citar o nome). Esse projeto foi ótimo para eu por em prática meus conhecimentos de Java. Nesse momento eu percebi que o pessoal de Java também gostava de falar mau do pessoal de DotNET. Na minha mente estava bem claro que isso era pura perda de tempo, pois claramente nos projetos que eu havia trabalhado eu pude perceber o valor de cada uma dessas tecnologias em cada contexto.

Passou o tempo e acabei não trabalhando mais com DotNET. As empresas seguintes foram todas com Java, exceto aqui na globo.com, onde voltarei a falar mais pra frente.

Muitos FUDs

Uma coisa que sempre percebi nessas brigas é que raramente usava-se argumentos lógicos e bem fundamentados. Geralmente as discussões eram baseadas em achismos e usavam algum argumento falacioso ou duvidoso/pouco claro.

Quando trabalhei para algumas empresas de Telecomunicações, Bancos e Seguradoras aqui no Rio de Janeiro, quase sempre havia um bom legado em COBOL e seus velhinhos de plantão dando manutenção nesses sistemas. Volta e meia eu ouvia algo do tipo: “Esse negócio de Java é apertar botãozinho e ta tudo pronto. Homem que é homem programa em COBOL”. Isso não fazia o menor sentido e por mais que eu tentasse explicar pros caras que não era bem assim, não adiantava, já existia uma opinião sem fundamentos formada na cabeça deles.

Numa dessas últimas empresas que trabalhei (para um dos maiores Bancos do nosso país), eu era Arquiteto junto com mais 14 desenvolvedores em um projeto Java que precisava se comunicar com programas COBOL/CICS. Sabe o que os COBOLEIROS diziam? “Só usem java pra pegar o que for processado aqui no COBOL porque aqui é que aguenta o tranco. Esse negócio de Java só serve para a parte levinha“. Apesar de conhecer sobre todo o poder de processamento dos Mainframes, eu sabia que aquilo era apenas uma provocação, pois eu já havia trabalhado em sistemas web feitos com Java com volumes bem maiores que os desse sistema e tudo correu muito bem. Sendo assim, nem entrei em discussão sobre isso, pois eles já tinham se fechado para o assunto.

Nossos dias atuais

Hoje em dia está muito na moda o uso de linguagens dinâmicas como Ruby e Python para desenvolvimento de software, muitos deles aplicações web. Existem diversos casos de sucesso usando essas tecnologias, e mais uma vez surgem as brigas pra saber qual é a melhor: Ruby ou Python.

Não espere aqui uma opinião minha sobre o que é melhor entre as 2, pois isso não vai acontecer. Não porque eu não tenha preferências, mas simplesmente porque melhor ou pior sempre dependerá do contexto e não somente da tecnologia.

Python é uma linguagem muito usada no mundo opensource, tendo muitos aplicativos console e desktop desenvolvidos para linux. A primeira versão do Youtube foi escrita em Python (não sei se ainda é). O Google AppEngine apesar de suportar Java, foi construido para Python. Existem diversas iniciativas que usam Python e são bem sucedidas.

Ruby apesar de ser uma linguagem bem antiga (1993), só explodiu mesmo com a chegada do Rails (2004/2005). Antes disso ninguém ouvia falar de Ruby. Mesmo assim, Rails trouxe uma ascensão meteórica para o Ruby, surgindo um ecosistema incrível, com uma série de produtos bem sucedidos e documentações fantasticas, screencasts, entre outros. Destacou-se muito com as ferramentas de testes automatizados que tanto precisamos hoje em dia para desenvolvermos software com qualidade.

No time onde eu trabalho na globo.com, desenvolvemos projetos em Java, em Python/Django e Ruby on Rails (projeto atual). Cada uma das escolhas teve razões lógicas e seus benefícios (que se comprovaram). Essa versatilidade faz com que esse time possa trabalhar em praticamente qualquer projeto da empresa, já que tem conhecimento nas principais linguagens que a empresa trabalha. Isso é muito mais benéfico do que ficar preso a uma tecnologia, defendendo-a com unhas e dentes.

O Mito do não escala

Com o advento dessas linguagens dinâmicas, deu bem pra perceber como a maioria dos profissionais não entendia/não entende quase nada sobre escalabilidade de sistemas web. Assim como o COBOLEIRO falava que o Java não aguentava o tranco, começaram a falar que linguagens dinâmicas não escalavam, principalmente o famoso “Rails não escala”.

Certa vez eu lí um post de 2004 (antes do Rails) que já falava sobre esse mito de não escala. Vale a pena conferir aqui. E tem também um screencast mais recente(baixe o vídeo e assista) do Gregg Pollack que nos primeiros minutos mostra na maioria das vezes o que deixa um site lento. Dica: tem pouco a ver com a tecnologia usada.

Portanto, não caia nessa. Pesquise e aprenda como escalar sua aplicação, independente de você estar usando Python/Django Ruby/Rails, Java, DotNET ou qualquer outra tenologia do seu projeto.

Conclusão

Mesmo com essas 2 tecnologias (Ruby e Python) fazendo seu sucesso nos dias de hoje e tendo seu contexto para serem aplicadas, o pessoal ainda continua brigando pra defender a sua tecnologia preferida. Parece que cria-se uma paixão cega pela linguagem, como se fosse uma espécie de religião, saindo do racional e passando a ser totalmente irracional.

Dessa forma, meu conselho para todos os profissionais é que não entrem nessa de ficar defendendo sua tecnologia preferida e atirando pedra na tecnologia concorrente. Aprenda ambas e saiba onde e quando usar cada uma delas.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Pensando sobre essa situação imaginei nós, os desenvolvedores. Muitas vezes trabalhamos com muito stress, sobrecarga de trabalho e umas boas horas extras.

O que será que acontece quando sobrecarregamos um servidor? Quando estressamos o mesmo? Quando fazemos testes de carga e performance, vemos que num determinado momento o servidor não aguenta e literalmente abre o bico.

Agora, se os servidores (que são máquinas, não humanos) precisam estar abaixo da capacidade produtiva pra não perder sua qualidade, imagine pessoas sem um tempo pra respirar, pensar e descansar?

Trabalhar no limite da sua capacidade produtiva torna o trabalho improdutivo, apesar de ser contra-intuitivo, talvez.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Passeando um pouco pelo dicionário, algumas definições me chamaram um pouco a atenção:

• Criar: inventar; imaginar; dar existência a; desenvolver;
• Fabricar: executar ou fazer executar certos produtos por processos mecânicos; manufacturar; construir;

É difícil perceber a diferença? Acho que não …

Se formos na Wikipedia podemos encontrar algumas informações ainda mais relevantes. Vejamos parte do texto:

… trabalhadores manufaturam bens ou supervisionam o funcionamento de máquinas que processam um produto, transformando-o em outro. A maioria das fábricas atuais têm grandes armazéns e depósitos com equipamentos pesados, utilizados na produção da linha de montagem …

Oito anos atrás, Fowler escreveu sobre isso, explicando claramente que a parte de “fabricar” o software é geralmente uma simples task do ant ou um goal do maven ou alguma coisa no rake, etc.

Já foi falado zilhões de vezes nos foruns de tecnologia que fábrica presupõe trabalho repetitivo, fazer o mesmo produto várias vezes (você faz o mesmo software várias vezes ou quando precisa de uma cópia simplesmente faz um cp arquivo1 arquivo2?), desenvolvimento em fazes (i.e. waterfall). Portanto, não faz sentido comparar nosso trabalho com trabalho de fábrica.

O trabalho do desenvolvedor é criar o software, fazer design do código em todo o tempo, assim como os arquitetos da contrução civil fazem no autocad, ou no bom e velho papel. A diferença é que nós temos a condição de construir (i.e fabricar) o nosso software com custo “zero”. Não precisamos de pedreiros, tijolos, vigas, argamassa, etc. Agente usa o Ant, Maven, Rake, Make ou wathever ora bolas. É tudo de graça. O resultado do trabalho deles é físico, o nosso são bits e bytes.

O erro sempre foi fazer a associação: desenvolver = construir/fabricar. A associação mais correta é desenvolver = projetar/arquitetar/desenhar.

Até a próxima …

Post Footer automatically generated by Add Post Footer Plugin for wordpress.