Archive for June, 2007

Será que é tão bom assim trabalhar no Google?

Wednesday, June 27th, 2007

Todo mundo já deve ter lido em vários lugares vários motivos para querer trabalhar no Google. Mas até agora ninguém havia escrito nada sobre as coisas ruins de se trabalhar lá.

Eis que acontece o seguinte: pelo que eu entendí, um fulano que trabalhava para a Microsoft saiu da empresa para montar uma startup. Essa startup foi comprada pelo Google e conseqüentemente o cara virou funcionário do Google. Depois de um tempo esse cara foi contratado novamente pela Microsoft. Quando ele foi re-contratado, ele falou sobre suas experiências no Google comparando com as experiências que teve na Microsoft.

Então o contratador resolveu divulgar para a empresa toda (Microsoft) a opinião do ex-Google, e um anônimo pegou este e-mail interno da Microsoft e criou um blog anônimo falando sobre algumas coisas não tão boas sobre o Google e que ninguém até agora havia comentado.

Será que é verdade mesmo?

Programadores ou apertadores de botão?

Wednesday, June 27th, 2007

Ontem estava conversando com uns amigos sobre os novos programadores que estão surgindo por aí, especialmente os que usam o Visual Studio .Net. O Visual Studio nem parece que foi feito para pessoas que sabem programar. Muitas vezes não dá para fazer certas coisas programando código mesmo, você é obrigado a usar um dos milhares de wizards da ferramenta.

Um dos meus amigos estava contando que quando ele começou a programar estava precisando colocar um combo box numa página e os itens deste combo precisavam ser lidos de uma tabela do banco de dados. Ao procurar na internet para descobrir como isso era feito, as únicas referências que ele encontrou eram de wizards! Simplesmente ele não conseguia encontrar uma página que mostrasse o código para fazer o que ele queria.

Eu ainda não tirei minhas conclusões definitivas sobre isso. Ás vezes eu acho que as pessoas estão ficando preguiçosas, ás vezes eu acho que falta mesmo qualificação para os programadores e ás vezes eu acho que é tudo isso ao mesmo tempo. Ultimamente a quantidade de gente desse tipo tem aumentado muito por aí. As novas ferramentas de desenvolvimento estão tornando os programadores em apertadores de botão!

Programar é uma atividade intelectual que exige conhecimento técnico (linguagens, plataformas, sistemas operacionais, tecnologias), conhecimento específico sobre o negócio para o qual o sistema é desenvolvido, capacidade de resolver problemas e criatividade. Quanto mais as pessoas se preocuparem em aprender sobre ferramentas ao invés de tecnologias e práticas de desenvolvimento, mais vão surgir os apertadores de botão e as características acima vão sendo substituídas por conhecimentos de wizards, opções da ferramenta e botões diversos que fazem coisas mágicas.

Na semana passada saiu um artigo na Artima entitulado Visual Development versus Coding que fala exatamente sobre isso.

A opinião do David Intersimone é a mesma que a minha: é muito legal ter ferramentas visuais para te ajudar a fazer as coisas, note bem, para AJUDAR. Mas se você precisar (e vai), você tem que saber codificar.

Monitore seu sistema com iStat menus

Sunday, June 24th, 2007

A iSlayer anunciou em seu blog o lançamento do iStat menus, um software muito legal que serve para monitorar o seu sistema de forma simples e rápida.

Ele mostra no menubar do Mac OS X várias informações importantes como utilização de CPU, memória, tráfego de rede, IO de disco e algumas coisas mais. Clicando no item monitorado você tem informações mais detalhadas. Veja como ficou o meu menubar com o iStat:

iStat menus - monitor de CPU

Antes eu usava o MenuMeters mas o iStat tem algumas informações a mais como temperatura e rotação dos coolers, além de ser bem mais bonito.

Para quem não gostar da idéia de instalar coisas no menu (tem gente que acha que fica muito poluído) eu recomendo o iStat Pro que é um dos melhores widgets de Dashboard que existem!

Infelizmente não tem nada disso para Windows. Sendo assim, mexa seu traseiro e troque essa sua lata velha por um Mac (calma, não vamos criar mais um flame war por causa disso, afinal não teria a menor graça porque o Mac ganharia fácil)!

Para mais detalhes acesse o site do iStat menus.

Asshole-Driven Development

Thursday, June 21st, 2007

Isso mesmo: desenvolvimento guiado por idiotas.

Scott Berkun, autor do livro The Myths of Innovation (que está na minha fila de livros para ler) escreveu um post muito bem humorado no seu blog, entitulado Asshole-Driven Development. Ele descreve várias “metodologias” de desenvolvimento de software amplamente utilizadas em várias empresas (pelo visto não só no Brasil).

A metodologia que eu mais gostei foi essa:

Asshole Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.

Slides da palestra sobre TDD no RioJUG

Wednesday, June 20th, 2007

Estou disponibilizando os slides da palestra sobre Desenvolvimento Guiado por Testes apresentada no RioJUG no dia 19/06/2007.

Desenvolvimento Guiado Por Testes
View SlideShare presentation or Upload your own. (tags: tdd bdd)

Como o tempo ficou curto lá na palestra acabei não apresentando o último slide que contém alguns links interessantes para quem quiser conhecer mais sobre o assunto:

IDLs para REST

Monday, June 18th, 2007

Ultimamente têm se discutido muito se webservices REST precisam ou não de uma IDL (Interface Description Language) que seria mais ou menos o que o WSDL é para webservices SOAP.

Enquanto a discussão rola, alguns já começaram a desenvolver soluções, como é o caso de Thomas Steiner que lançou a versão 0.3 da sua ferramenta REST Describe & Compile tool.

Para ver que tipo de saída é gerada pela ferramenta, você pode testar a versão online do REST describe. Caso você não tenha uma URL para testar, use algum dos webservices da Last.fm (Audioscrobbler) como este que obtém os 50 artistas que eu mais ouço: http://ws.audioscrobbler.com/1.0/user/gchapiewski/topartists.xml.

CruiseControl 2.7

Sunday, June 17th, 2007

Acabei de ler no blog da ThoughtWorks sobre o lançamento de uma nova versão do CruiseControl.

Esta versão é a primeira lançada depois do anúncio do CruiseControl Enterprise, eu pessoalmente estava com uma expectativa grande para ver os resultados práticos desta mudança.

Dentre várias melhorias, a mais legal delas foi o novo dashboard que possibilita que você saiba rapidamente o status dos builds do seu projeto, dentre outras informações. Além disso será possível desenvolver os seus próprios widgets e montar uma tela com todas as informações do projeto que você desejar!

Otimização prematura

Friday, June 15th, 2007

Dando uma olhada em uns projetos que estavam no meu Eclipse encontrei um projeto antigo de uma empresa que eu trabalhei. Esse projeto teve o desenvolvimento mais curto da história: 1 dia! É sério, ele acabou no mesmo dia que começou por uma série de razões.

Mais isso foi só uma pequena introdução, a história de verdade não é essa. Dê uma analisada num trecho de código deste projeto que foi desenvolvido por alguém lá da equipe (detalhe: leia atentamente o comentário):

public class Usuario implements BussinessObjectModel {
 
    protected UsuarioDTO usuarioDTO;
 
    public void login() throws Exception {
        if(this.usuarioDTO == null || this.usuarioDTO.getSenha() == null || this.usuarioDTO.getUsuario() == null) {
            throw new Exception("Erro");
        }
 
        /**
         * TODO: codigo do login.
         * ir no banco de dados, decriptar a senha, comparar
         * com o cara. logar no JMS, mandar um SMS, atualizar
         * o cache de usuarios, fazer uma chamada ejb remota
         * dizendo que o usuario entrou.
         */
    }
}

Donald Knuth já dizia que a otimização prematura é a raiz de todo o mal. Mas acho que quando ele disse isso jamais imaginaria uma otimização TÃO prematura. Em toda a minha vida esse foi um dos maiores exemplos de overdesign que eu já ví!

Repare: era o primeiro dia do projeto. Nem sabíamos direito o que precisava ser feito e o cara já decidiu que a aplicação deveria ter DTOs, JMS, EJB e cache de usuários… Sem sequer pensar no problema o programador decidiu adicionar uma complexidade enorme e desnecessária ao sistema.

Quando se desenvolve um projeto de software, a primeira coisa que deve-se fazer é atender aos requisitos funcionais do cliente da forma mais simples e rápida possível. Em seguida faz-se refactoring do código para que ele seja melhorado e no futuro possa se adaptar melhor a eventuais mudanças. E só.

Isto significa que neste momento você não se preocupa com cache, por exemplo. Se por acaso algum dia houverem problemas de performance, aí sim, pensa-se em cache, distribuição da aplicação e etc. Neste caso esta aplicação estava prevista para ter pouco mais de 10 usuários simultâneos, uma quantidade de acessoss ridícula para se pensar em otimização.

Os desenvolvedores têm uma mania horrorosa de overdesign, especialmente os desenvolvedores Java. É preciso parar de tentar adivinhar o futuro e se concentrar mais nos problemas que precisam ser resolvidos agora. Deixe os problemas do futuro para serem resolvidos no futuro!

Como produzir software “coxa”

Friday, June 8th, 2007

Acabei de ler um post no blog do Phillip que me lembrou de uma história que eu queria escrever aqui.

A história que você lerá a seguir é uma dramatização do que acontece diariamente no mundo do desenvolvimento de software carinhosamente entitulada Como desenvolver software “coxa”.

Imagine uma empresa que está com necessidades de desenvolver um software. E imagine também que esta empresa (cliente) contratou uma empresa de 3 letras para fazer o trabalho.

Então, o projeto começa com a empresa contratada fazendo uma análise extensa do que será desenvolvido. Caso você não saiba, estas empresas te fazem acreditar que o RUP tem uma fase de análise antes de tudo, quando isso na verdade caracteriza um processo de desenvolvimento waterfall que é bem diferente do processo de desenvolvimento iterativo do RUP.

Depois de analisar exaustivamente tudo que precisa ser feito, eles acham que sabem tudo que o cliente precisa e com isso acham que sabem exatamente quanto tempo irá levar. Baseado nisso é estipulado um prazo de entrega do software para o cliente, assim como é estipulado um preço fixo para o trabalho.

Fechado o contrato, o projeto é iniciado. E quando começa o projeto sempre acontece a mesma coisa: a equipe de desenvolvimento começa a descobrir que certas coisas não são tão simples quanto pareciam ser. A equipe se depara com vários problemas que não haviam aparecido na fase de análise e cada vez fica mais chocada com a quantidade de coisas novas que vão surgindo. Nesse momento a equipe percebe que o projeto, que estimou-se que precisaria de 4 meses para ser desenvolvido, na verdade precisa de 8 meses para ser desenvolvido!

Então alguém surge com a brilhante idéia de contratar mais pessoas para a equipe. Afinal de contas, da mesma forma que nove grávidas conseguem parir um filho em um mês, 20 desenvolvedores conseguem fazer na metade do tempo o trabalho que 10 fariam – parece perfeito!

Mas espera aí, o preço já está combinado com o cliente desde o início. Então contratar mais pessoas é a maior furada, porque o cliente não pagará nada a mais por isso e se o custo do projeto for maior a empresa não terá lucro. Pior ainda, a empresa pode ter prejuízo! Neste momento a empresa decide comuncar ao cliente que o projeto terá que atrasar.

Quando a empresa vai dar a notícia para o cliente o cara normalmente quer matar o gerente do projeto, quer se matar, ou OS DOIS (depende do tamanho do projeto)! Afinal de contas ele pagou 50% adiantado e quer logo o retorno do seu investimento. Se o projeto ia demorar 4 meses e agora vai demorar 8, significa que todo o seu planejamento financeiro e de retorno de investimento do software foram por água a baixo. Nesse momento o cliente bate na mesa com força e diz: “se virem, eu não quero nem saber como vocês vão fazer mas eu quero o meu software na data combinada!”.

Exatamente neste momento foi parido um software “coxa”!

Vou explicar fazendo uma analogia: qualquer criança de 10 anos sabe que não existe “bom, bonito e barato”. Ou é bom, bonito e CARO; ou é RUIM, bonito e barato; ou é bom, FEIO e barato. Não tem jeito, é assim que funciona, não é possível ter tudo ao mesmo tempo.

Com software funciona exatamente da mesma forma. Só o que muda são as dimensões: qualidade, tempo e custo. Da mesma maneira que não existe nada bom, bonito e barato, não existe software “bom, desenvolvido rápido e barato”. Ou é bom, desenvolvido rápido e CARO; ou é bom, DESENVOLVIDO EM MUITO TEMPO e barato; ou é RUIM, desenvolvido rápido e barato.

No caso deste projeto repare que duas das dimensões do software não podem ser alteradas: preço (porque já foi combinado com o cliente e está em contrato) e tempo (porque a data de entrega já está estipulada). Sendo assim, como não dá para ter tudo ao mesmo tempo, a qualidade vai para o brejo. Neste momento é que vem a ordem do gerente de projeto: “gente, faz qualquer coisa aí, o importante é entregar o que foi combinado com o cliente, não importa como, faz tudo nas coxas mesmo!!”. E mais um software “coxa” será entregue.

Se eu contar os softwares “coxa” que eu já ví por aí ninguém acredita. O mais bizarro deles e que não poderia deixar de ser citado tinha o seguinte código na tela de autenticação (PHP):

if (($_REQUEST["login"]  == "admin") && ($_REQUEST["senha"]  == "1234")) {
    header("Location: index_autenticado.php");
} else {
    header("Location: index.php?mensagem=Login%20invalido");
}

No final das contas, quando o projeto é entregue, o cliente vê as telinhas e se as telinhas estiverem aparecendo e estiverem no mínimo bonitinhas ele vai dar pulos de alegria! Eventualmente até irá contratar a empresa para outro projeto ou indicar para amigos e outros projetos dentro da sua empresa. Por baixo dos panos existe esse monte de lixo, mais ou menos como um vulcão que pode entrar em erupção a qualquer momento causando efeitos devatadores! Deixa só alguém pedir para trocar a senha do sistema para ver o que vai acontecer…

Para mim é claro como água: não adianta querer prever tudo que acontecerá no projeto e pré-fixar datas e valores. É receita certa para fazer lixo. Já está mais do que provado que não funciona, porque insistir no mesmo erro?

Se você que está lendo se identificou com a história (o que não é nem um pouco difícil), sugiro fortemente que você leia sobre um modelo de contrato de desenvolvimento de software proposto pelo XP que muito me agrada: o Contrato de Escopo Negociável. O artigo é bem grande mas vale apena ler até o final! Você vai perceber que as coisas não precisam ser assim tão tristes nos projetos de desenvolvimento do software.

Palestra sobre TDD no RioJUG

Wednesday, June 6th, 2007

No dia 19/06 farei uma apresentação no RioJUG sobre TDD:

“Test Driven Development (Desenvolvimento Guiado por Testes) é a prática de escrever testes unitários de um software antes de escrever o código que está sendo testado. O TDD é uma prática utilizada em metodologias ágeis de desenvolvimento de software como o XP (eXtreme Programming). Esta palestra apresentará conceitos de TDD utilizando exemplos simples e de fácil entendimento. Serão apresentadas também suas vantagens, desvantagens e comparações com outros tipos de testes de software comumente utilizados.”

Para mais detalhes acesse a página do evento no site do RioJUG.

Apareçam por lá! :)