codificando.com

Cansado das briguinhas recentes em listas de discussão, blogs e foruns sobre Ruby x Python, resolvi escrever sobre o assunto de forma totalmente imparcial. Serei imparcial, não por causa do blog, mas porque com esse tipo de assunto eu sempre geralmente sou imparcial, pois pela diversidade de empresas que trabalhei durante os meus mais de 12 anos de carreira, acabei sempre trabalhando com as 2 linguagens que eram o motivo da briguinha, em cada época distinta.

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.

Depois de programar algum tempo em Ruby, me senti muito incomodado em ter que repetir um determinado código para manter minha estrutura respeitando a Law of Demeter. Pra quem não está familiarizado, segue um simples exemplo em Rails:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
end

#view - erb|haml
@comment.post.title
@comment.post.name
@comment.post.something_else

O exemplo é um pouco forçado, mas o problema claro do exemplo é que estamos conhecendo demais sobre o objeto post dentro de comment. Se for necessário alguma alteração em algum dos atributos que estamos acessando diretamente, possivelmente isso resultará em modificações em cascata em todo código.

Depois dessa explicação básica para quem ainda não conhecia a Law of Demeter, vamos aplicar algumas soluções:

Segunda tentativa:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  belongs_to :post
  def post_title
    post ? post.title : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
  def post_name
    post ? post.name : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
  def post_something_else
    post ? post.something_else : nil #preciso verificar se é nulo, caso contrário terei problemas
  end
end

#view - erb|haml
@comment.post_title
@comment.post_name
@comment.post_something_else

Essa mudança resolve o problema. Acontece que isso acaba sendo um pattern para resolver o problema, portanto, precisamos encontrar uma forma de não ficar repetindo esse código.

Quem já leu o livro The Pragmatic Programmer, tem bem na memória o capítulo que apresenta o conceito DRY – D’ont Repeat Yourself. Quem programa em Ruby e principalmente já usou o framework Rails sabe bem que DRY é um dos chavões que estão imbutidos na propaganda. Vamos então tentar fazer mais algumas modificações pra tentar alcançar esse objetivo:

Terceira tentativa:

#models
class Post < ActiveRecord::Base
  has_many :comments
end

require 'forwardable'
class Comment < ActiveRecord::Base
  extend Forwardable
  belongs_to :post
  def_delegator :post, :name, :post_name
  def_delegator :post, :title, :post_title
  def_delegator :post, :something_else, :post_something_else
end

#view - erb|haml
@comment.post_title
@comment.post_name
@comment.post_something_else

O módulo Forwardable já vem com o Ruby. Portanto, a solução mais obvia foi usar esse módulo para melhorar o exemplo anterior. Apesar de escrever menos código, essa alternativa tem o inconveniente de não verificar se o objeto post é nil, causando assim NoMethodError em alguns casos. Sendo assim, a alternativa anterior ainda parece ser mais adequada. Porém, a duplicação de código ainda me incomodava bastante, portanto, resolvi montar uma solução única que deu origem a gem demeter.

A solução definitiva:

#no shell
> sudo gem update --system
> sudo gem sources -a http://gemcutter.org
> sudo gem install demeter

#models
class Post < ActiveRecord::Base
  has_many :comments
end

class Comment < ActiveRecord::Base
  extend Demeter     #extends demeter module
  demeter :post      #demeter post object
  belongs_to :post
end

#view
@comment.post_title
@comment.post_name
@comment.post_something_else

Basicamente o problema foi resolvido com 2 linhas de código:

  extend Demeter
  demeter :post

A vantagens são visíveis porque (1) você escreve bem menos, (2) já existe a verificação de objetos nulos e (3) caso você queira sobrescrever o comportamento padrão, basta criar um método que responda a mesma mensagem que a gem demeter responde. Dessa forma, o método criado pelo programador semrpe terá prioridade.

O código fonte do projeto está em http://github.com/emerleite/demeter com todas as instruções para utilização tanto em Ruby quanto em Ruby on Rails. O código fonte tem todos os testes automatizados que cobrem diversos cenários. O resultado desses testes podem ser vistos em http://runcoderun.com/emerleite/demeter. A página da gem fica em http://gemcutter.org/gems/demeter

Aguardo o feedback de vocês

Certo dia um amigo com alguns bons anos de experiência e trabalhando na função de pleno, achou que era a hora de mudar de cargo para sênior. Chegando no seu gerênte, recebeu a seguinte resposta: “fulano, não posso te passar pra sênior porque você não conhece o framework xyz e a lingaugem abc“. Esse meu amigo chegou perto de mim bem cabisbaixo e me contou o que tinha acontecido. Simplesmente achei o fato ridículo. Talvez ele realmente não fosse o momento de se tornar sênior (i.e. em relação ao cargo), mas esse argumento realmente não cola.

Como já mencionei em outros posts nesse mesmo blog, nossa área de desenvolvimento de software/informática está cheia de termos/nomenclatura que se confundem facilmente (e.g. as discussões no GUJ sobre DTO). Mais uma vez, falarei sobre um deles: a classificação júnior, pleno, sênior.

Dando uma passeada pelos sites de emprego de informática, é fácil ver vagas para analista de sistemas / programador / desenvolvedor júnior, pleno e sênior, etc. Acontece que a maioria das pessoas (inclusive os gerêntes de TI) não sabem muito bem fazer essa distinção entre os níveis, causando uma grande confusão na cabeça de todo mundo, inclusive na hora de negociar o cascalho. Portanto, vamos começar pelo básico …

Não sou uma pessoa entendida de RH, muito menos sei a história sobre como começou essa nomenclatura de júnior, pleno e sênior. Mas como trabalho na área de TI faz 12 anos e já passei por um bocado de empresas, acho que posso dar meu pitaco sobre o assunto. As melhores definições que consegui na internet para sênior foram: ancião, velho, pessoa com mais experiência em alguma profissão. De cara tem alguma coisa estranha na resposta que o tal gerente deu pro meu amigo, mas não para por ai.

No início da minha carreira, nas empresas onde passei, geralmente o cara sênior era um cara com mais experiência, uma pessoa que viveu mais situações, uma pessoa mais madura (não necessáriamente velha ou idosa). Por muitas vezes, essa pessoa não conhecia uma ferramenta ou outra de trabalho que eu conhecia, mas isso de maneira alguma me colocava no mesmo nível daquele profissional, pois tomando conhecimento da existência daquela ferramenta e utilizando um pouco do seu tempo, a tal ferramenta estava absorvida por este.

E o que eu quero dizer com isso? Eu quero dizer que se você começou agora, mesmo que você saiba python, ruby, java, erlang, haskell, xpto, brainfuck, você é Júnior ainda. Lógico que é ótimo saber diversas ferramentas e eu recomendo a todos estudar para isso. O mesmo princípio se aplica ao profissional sênior. Fatalmente tem algumas coisas que lhe fogem ao conhecimento, porém a diferência é que esse naturalmente conhece muitas ferramentas  devido a sua experiência ao longo dos anos. Não foi simplesmente um livro que leu ou um tutorial da internet que fez, mas projetos reais que participou. Um sênior deve saber debater com seus superiores sem medo, com argumentações bem formuladas, sabendo exatamente a sua posição, mas sem muito se intimidar quando conversa com outro profissional acima na hierarquia. Deve chamar a responsabilidade para si em momentos críticos, deve ajudar e ensinar os demais simplesmente porque isso é de sua responsabilidade.

Saber ou não uma determinada linguagem ou ferramenta não faz necessáriamente de você nem júnior nem sênior, pois isso as vezes depende da sua trajetória de carreira. Eu por exemplo não sei nada de ABAP, pois nunca trabalhei com SAP ou algo que use essa linguagem. Talvez você esteja aprendendo Java nesse momento mas tem 10 anos de experiência com C/C++ e tem ótimas práticas de programação. Em fim, é bem relativo.

Pra finalizar, certa vez um amigo me disse que sênioridade é algo como um estado de espírito. Vou até um pouco além disso. Acredito que sêrionidade é um estado avançado de profissionalismo aliado a maturidade alcançada ao longo do tempo.

Disclaimer:

Para que não pareça que defendo regime de quartel, quero deixar bem claro que hoje em dia de nada adianta você ser maduro e experiente se você é um profissional encostado e desatualizado. E o talento, é claro, sempre fala mais alto.

No mês passado, resolvi aplicar BDD em um projeto Java que estava desenvolvendo. Atualmente, existem ferramentas em outras linguagens que podem ser usadas para esse fim. Por uma série de razões, resolvi usar o JBehave para resolver o meu problema nesse projeto em específico (lembre-se, não existe bala de prata). Acontece que o JBehave é todo em Inglês e não dá suporte a i18n.

Quando comecei a usa-lo no meu projeto, logo percebi que usar em inglês não seria legal, pois o projeto só fazia sentido no Brasil e portanto o interessante era escrever os cenários em português. A partir desse momento, comecei a escrever algumas classes pra fornecer esse suporte. Felizmente, as classes Scenario e Steps permitem fácil extensão para resolver esse problema. Após as modificações necessárias, o arquivo de cenário passou a se chamar nome.cenario e o texto no arquivo ficou da seguinte forma:

Cenário: Nome em português do Brasil

Dado que eu quero rodar o Jbehave em português do Brasil
Quando eu usar o meu idioma
Então tudo deve funcionar perfeitamente

Feito isso, achei legal disponibilizar uma biblioteca para que outros desenvolvedores que precisem usar o JBehave no nosso idioma possam faze-lo de forma trivial. Nesse momento nasceu o projeto jbehave-br, extraido desse projeto e disponibilizado no GitHub aqui. O projeto é muito simples e pequeno, com o objetivo de resolver especificamente esse problema e nada mais.

Depois de criar o projeto, pervebi que seria simples modifica-lo para posteriormente suportar qualquer idioma. Em breve estarei liberando essa nova versão. Por conta disso o projeto talvez mude de jbehave-br para outro nome.

Outro dia aqui na globo.com, estavamos numa reunião com uma determinada equipe que cuida de infra-estrutura sobre um projeto do meu time que estamos desenvolvendo. Num determinado momento da reunião, quando conversavamos sobre um determinado servidor de banco de dados, uma pessoa da equipe de infra disse que esse tal servidor estava dormindo (i.e. Trabalhando bem abaixo da sua capacidade). Como nosso projeto demandará grande volume, esse servidor será melhorado para que suporte nosso projeto e continue “dormindo”.

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.

Sempre que eu ouço a frase “Fábrica de Software” meus ouvidos doem bastante. Outro dia, conversando com algumas pessoas, havia um colega que não entendia muito bem a minha aversão por essa tal de “Fábrica de Software”. Após explicar que software é um trabalho criativo, ficou uma dúvida entre algumas pessoas. Afinal de contas, qual a diferença entre criar e fabricar?

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 …

Faz quatro meses que estou aqui na globo.com. Nesse pouco tempo, muita coisa aconteceu. Projetos

frenéticos, coisas de BBB que me proporcionaram uns cabelos brancos (os primeiros eu acho rs) e uma galera muito show de bola que trabalha aqui comigo.

Nesses quatro meses, estive aqui pela Concrete Solutions, empresa na qual também trabalha o Bruno Pereira, o qual está deixando hoje a globo.com.

Na semana retrasada, fui procurado pelo nosso gerente de desenvolvimento Danilo Bardusco com uma proposta para me tornar funcionário da globo.com. Após algumas conversas, chegamos a um acordo e agora sou mais um global

E quais serão os próximos passos heim?

A Revista Visão Ágil, que sempre apresenta artigos muito interesantes, publicou este mês de outubro a edição número 5 com um artigo meu sobre Os 7 Pecados Capitais de Um time Ágil. O editorial está de parabéns pelo trabalho que fizeram. Realmente a revista ficou ótima.

O Artigo fala um pouco sobre erros comuns de times ágeis. Isso inclui não somente o time, mas P.Os, Scrum Masters e todos os demais envolvidos. Vale a pena conferir.

Os demais artigos também são de excelente qualidade e a leitura dos mesmos é extremamente recomendada.

Meus sinceros agradecimentos ao Manoel Pimentel e Felipe Rogrigues.

Quem não se lembra do comercial da Oi sobre bloqueio de celulares que fez bastante barulho?

O bloqueio as vezes faz parte da vida do Desenvolvedor de Software. Em muitas empresas que trabalhei, tive que conviver com alguns. Foram eles:

• Bloqueio da Internet (Parece mentira, mas trabalhei num lugar onde somente algumas equipes tinham acesso a internet)
• Bloqueio de Instant Message
• Bloqueio de email (Não dava pra acessar o Gmail)
• Bloqueio do Internet Banking
• Bloqueio de alguns sites (Eu não conseguia acessar alguns blogs importantes)
• Bloqueio do Telefone (Não dava nem pra ligar pra casa e em algumas empresas nem telefone na mesa tinha)
• Bloqueio da estação de trabalho (Como que um desenvolvedor que não pode instalar nada no seu computador consegue trabalhar?)
• Bloqueio da Impressora (Tinha senha especial pra imprimir)

Depois de sofrer bastante com esses bloqueios eu me interessei em saber o motivo que leva muitas empresas a trabalhar dessa forma. Apesar do argumento deles ser furado, vou listar o que eu ouvi de diversas pessoas:

• Perda de produtividade (segundo eles, as pessoas perdem muito tempo com coisas inúteis na internet e telefone)
• Falta de foco dos funcionários (Pessoas se desconcentravam facilmente com o IM e outros)
• Desperdício de recursos da empresa. (Gente imprimindo e usando o telefone demasiadamente)

Depois disso, passei a observar o comportamento das pessoas pra ver como cada um se resolvia com essa série de bloqueios. Eis o que percebi:

• A ausência da Internet gerava falta de produtividade, pois os desenvolvedores não conseguiam pesquisar algumas coisas, não tinham forum de discussão e não se mantinham atualizados lendo alguns blogs de tecnologia
• A ausência do Instant Message impedia que um desenvolvedor pedisse ajuda a algum colega que já tenha trabalhado com ele para solucionar um determinado problema.
• A falta do email fazia com que houvessem notebooks com internet móvel espalhados pela empresa para que o pessoal conseguisse ler seus emails.
• A impossibilidade de instalação de softwares na máquina do desenvolvedor fazia com que o mesmo perdesse mais tempo que o necessário para resolver determinados problemas.
• Muitos criaram seu prórpio jeito de burlar isso tudo (Proxys anônimos, senha de admin das máquinas escondido, mais tempo de almoço pra telefonar e imprimir em lan-houses)

E o pior: Essas empresas PERDERAM ÓTIMOS PROFISSIONAIS.

Atualmente eu trabalho numa empresa onde não tem dessas coisas. Aqui nossa internet é totalmente liberada, podemos usar o telefone sem problemas, enviar email a vontade, pagar nossas contas e até mesmo usar o Instant Message (MSN, Yahoo, ICQ, Gtalk), que é considerado por muitos um absurdo.

A conclusão que eu cheguei foi que não importa o que a empresa faça, se o desenvolvedor não quiser trabalhar, ele vai dar um jeito de faze-lo, mesmo que seja burlando as coisas ou simplesmente levando um livrinho e passando o dia lendo na sua mesa.

O que a sua empresa precisa é contratar profissionais de verdade e não pessoas que simplesmente querem um emprego, pois quem quer realmente trabalhar, usa esses recursos a favor da empresa e não contra.

Para aumentar a produtividade e diminuir os custos, recomendo ainda introduzir alguma filosofia de trabalho ágil na sua empresa.

Quem ama não bloqueia !!!

Faz alguns meses que os gujeiros Rodrigo Yoshima e Carlos Villela blogaram sobre o uso errado da tecnologia numa fábrica de pastas de dentes. Para resolver o problema de caixas vazias que passavam desapercebidas numa linha de produção, a empresa comprou uma ultra-mega-power solução que ainda acabou atrapalhando os trabalhadores da fábrica. Mas os próprios trabalhadores se encarregaram de comprar um ventiladorzinho de 20 dólares e dispensar o mega equipamento.

Quem é Brasileiro e principalmente presenciou as corridas de nossos grandes pilotos de Fórmula 1, provavelmente ainda acompanha a categoria, mesmo que exporadicamente. Eu, criado em uma família muito ligada a esportes, com forte inclinação para F1(por que será que meu nome é Emerson? Alguém consegue advinhar? rs), continuo acompanhando os campeonatos, na esperança de que um brasileiro novamente seja campeão mundial.

Eis que no primeiro GP noturno da história da F1 a Ferrari atrapalhou Felipe Massa durante o seu pit-stop com um equipamento ultra moderno que foi desenvolvido para substituir o tradicional pirulito, durante os pit-stops. Esse pirulito foi utilizado por mais de 20 anos e que sempre se mostrou adequado. O novo equipamento fica posicionado em uma altura acima da cabeça do piloto, o que dificulta a visualização em caso de uma nova instrução para parar. O piloto brasileiro perdeu uns 30 segundos pois a mangueira de combustível rompeu-se e sua corrida foi comprometida, inclusive comprometendo a possibilidade de conquiista do campeonato. No pit-stop seguinte, na mesma corrida, a Ferrari voltou a usar o pirulito e no GP seguinte, aposentou de vez a sua engenhoca.

Uma das filosofias que mais gosto para Desenvolvimento de Software nos tempos atuais é KISS. Eu até hoje não sei o motivo de querermos fazer as coisas de forma complicada ao invés de simplificar (eu mesmo já errei muito nisso). Note que simples não significa sem qualidade, mas fazer o suficiente que possa atender a necessidade. As metodologias ágeis da moda como SCRUM / XP falam muito sobre isso. A prática de TDD também tem esse foco, quando prega que devemos fazer o código mais simples possível que atenda a necessidade em questão. E não poderia me esquecer do tão importante princípio de Baby Steps, utilizado em tudo isso que mencionei anteriormente.

Eu sinceramente acho que esse problema é inerente do ser humano e nós é que devemos nos doutrinar pra não cair nessa besteira.