Mergulhando no caos

Mudança

2006-11-24T15:15:00.000-08:00

Esta pequena casa aqui no Blogger tem me servido muito bem há mais de um ano, mas chegou a hora de se mudar.

Estou acabando de desempacotar a última caixa da mudança. Meu novo endereço é http://thiagoarrais.wordpress.com e já tem artigo novo por lá. Este blog não será mais atualizado e quem quiser pode ler tudo que há aqui no novo endereço também. O endereço do feed RSS continua o mesmo: http://feeds.feedburner.com/MergulhandoNoCaos, mas se você tentar abrir a versão web a partir do feed será direcionado para o novo endereço.

Veteranos e novatos

2006-10-29T11:30:00.000-08:00

Este é o último artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

Muita inovação acontece nas margens do sistema, pelas mãos de quem ainda não faz (ou nunca vai fazer) parte das panelinhas que todo mundo presta atenção.

Quem está em destaque tem uma certa obrigação oculta de continuar fazendo sucesso. Isto não está escrito em lugar nenhum, mas eles se sentem pressionados mesmo assim. Por causa dessa pressão invisível é que eles tendem a se concentrar em atividades de baixo risco. Uma das práticas de baixo risco mais comuns é repetir seu primeiro grande feito à exaustão. Se você já descobriu algo que faz sucesso, porque arriscar? Veja Dan Brown, por exemplo. Depois que ele escreveu O Código Da Vinci e o livro apareceu em listas de mais vendidos do mundo inteiro, ele já o reescreveu algumas vezes. Claro que o título e o enredo mudam toda vez, mas a estória é essencialmente a mesma. Ele faz isso porque dá certo. As pessoas compram os livros dele porque sabem o que esperar.

Repetição não é ruim. Repetição é um dos elementos fundamentais da evolução. Quando os animais se reproduzem eles basicamente se repetem, fazem cópias de si mesmos. Se essa repetição fosse exata, o que chamamos de clonagem, não haveria evolução porque não haveria mudança. Mas na vida real o que acontece é que a estrutura básica é repetida e mudam-se alguns detalhes menores como a cor dos olhos, a espessura dos pêlos e a estatura. A partir destas pequenas diferenças é que ocorre a evolução. O mesmo ocorre com as idéias de sucesso. Sua estrutura principal é repetida e alguns detalhes são modificados. De acordo com a receptividade, estes detalhes são novamente modificados e novas mutações são testadas.

Os veteranos em todos os ramos são muito bons nesse tipo de evolução experimental, eles podem mudar pequenas coisas de modo a gerar coisas novas mas extremamente parecidas com as antigas. Este processo é lento por natureza. Para chegar a um novo produto desse modo é necessário fazer várias modificações e cada uma das modificações precisa ser testada para a aceitação do público. Isto leva tempo.

Mas às vezes o que precisamos não é de evolução lenta. Às vezes precisamos de saltos evolucionários para não ficarmos presos em máximos locais. Para isso é necessário introduzir um elemento inesperado, uma fonte de aleatoriedade qualquer. Na natureza, a reprodução sexuada vem cumprindo muito bem esse papel e nos negócios sangue novo também é muito bom para isso. Os novatos não tiveram as idéias influenciadas pelas limitações atuais do mercado e da tecnologia, por isso têm facilidade para pensar em coisas completamente novas.

Essas limitações podem ser um grande problema. As idéias novas parecem preferir as cabeças mais frescas. Quando se está no meio da selva matando um leão por dia, fica difícil achar tempo para ter grandes idéias e pensar no futuro. Muita gente acaba queimando a língua por causa disso.

Há controvérsias, mas algumas fontes relatam que Thomas Watson, então presidente da IBM, disse em 1943 que talvez houvesse no mundo inteiro mercado para cinco computadores. Era a época da Segunda Guerra Mundial. Os computadores eram usados principalmente para quebrar códigos de mensagens militares e eram grandes a ponto de ocupar várias salas. Naquela época não havia a sala dos computadores, mas as salas do computador.

Nessa situação é fácil imaginar que o mundo teria poucos computadores. Era preciso ter muitos recursos para isso e as únicas entidades com recursos e interesse suficientes para obter um eram uma meia-dúzia de governos.

Já a revista Popular Mechanics, em uma edição de 1949 acertou em cheio. Eles publicaram que "no futuro, os computadores pesarão não mais do que uma tonelada e meia." Algumas décadas depois realmente é difícil achar um computador com uma tonelada e meia. Mas é fácil encontrar um com alguns gramas no bolso de qualquer adolescente.

Em 1977, quando a Apple lançava seu computador pessoal Apple II, Ken Olsen, fundador da Digital Equipment disse que não via razão para alguém querer um computador em casa. A DEC produzia o que eles chamavam de mini-computadores que eram usados principalmente para pesquisa científica. Realmente, ninguém iria querer um desses em casa, mas hoje muita gente não sabe como iria viver sem um computador pessoal.

Os produtos realmente inovadores são surpreendentes porque ninguém acha que precisa deles antes de existirem. Ninguém precisava do computador pessoal antes dele existir. Ninguém precisava de celulares. Ninguém precisava de câmeras digitais. Ninguém precisava de mouses. Mas hoje tem muita gente que não sabe como vivia antes deles.

Todas estas pérolas são de gente que já estava envolvida em seus respectivos nichos há um certo tempo. Eles simplesmente não conseguiam ver os saltos evolucionários. Eles estavam muito ocupados resolvendo os problemas de hoje e não tinham tempo para pensar nos de amanhã.

Os novatos não têm essas limitações ainda. Eles não foram tão expostos à situação atual como os veteranos. O problema deles é outro: recursos.

Semana passada eu li sobre como as telecom estão querendo estratificar a Internet para cobrar direitos de transmissão sobre os meios de alta velocidade. Na ponta dos links da Internet estão os roteadores e eles têm uma fila interna. A idéia é que se você pagar mais, seus pacotes (suas mensagens) tenham prioridade de transmissão. Atualmente, a fila é mais ou menos justa: se você chegar primeiro, você é atendido primeiro. O que eles querem é que algumas pessoas possam furar a fila.

Se elas conseguirem fazer isso (e eu não tenho certeza de que seja possível), vai ser um grande golpe para a inovação. Muitas das idéias inovadoras de hoje saem das cabeças das pessoas comuns e elas não têm os recursos que as grandes corporações têm. Se as filas de transmissão não fossem igualitárias, não seria possível que um programador de São Francisco inventasse e testasse o BitTorrent. Se os grandes provedores de conteúdo tivessem preferência de tráfego, ele não poderia fazer suas experiências usando sua conexão residencial comum. Os pacotes dele teriam prioridade extremamente baixa e ficariam um bom tempo presos no congestionamento. Seria preciso convencer algum investidor com bom poder de fogo a financiar o projeto. E os investidores podem não ser muito receptivos à inovação.

Inovar é arriscado e quando você é velho e famoso, não pode se dar ao luxo de fazer papel de idiota. Mas se você é jovem e desconhecido, ninguém vai ficar sabendo do seu fiasco. Você pode ousar mais quando não tem medo de bancar o idiota.

Aprender, praticar (e aprender um pouco mais)

2006-10-23T22:56:00.000-07:00

Este é o segundo artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

Prática certamente é uma Boa Coisa™. Eu até acredito que tem algumas coisas que não dá para aprender sem praticar. Para estas (e elas são muitas) é mais interessante estudar um pouco, praticar um pouco, depois estudar mais um pouco e repetir o ciclo eternamente. Você não pode dizer que sabe sobre alguma coisa antes de usá-la de verdade. Mas conhecimento prático somente, não é suficiente.

Se eu quiser programar, por exemplo, não basta que eu devore o manual de alguma linguagem de programação e comece a escrever meus próprios programas. Eu até posso fazer isso, se eu quiser só programar. Mas se eu quiser fazer bem, é preciso estudar como quem já está nessa há mais tempo faz as coisas. Se eu simplesmente me trancar no meu quarto de madrugada para programar, a excelência vai ser um objetivo distante. Alcançável, mas bastante distante. É preciso ler código dos outros, procurar por construções comuns em vários programas e identificar boas práticas.

Mas isto não é o bastante. Se eu quiser mesmo ser Bom com 'B' maiúsculo, vou precisar estudar algumas coisas que aparentemente não têm nada a ver com o ofício da programação. Coisas como teoria dos grafos, protocolos de comunicação entre computadores e inteligência artificial. Mesmo que eu ache que não vá usar diretamente nada disso, é bom me expor pelo menos um pouco a estes assuntos.

Estudar tudo isso vai alargar meus horizontes de conhecimento. Eu não vou saber nenhum desses assuntos a fundo, mas vou saber que há outros mares para explorar, novas possibilidades. Assim podemos traçar paralelos e estabelecer analogias que podem levar a idéias geniais. Não é preciso mais do que uma breve exposição para isso.

Ter uma noção de cada assunto é ter conhecimento horizontal. É o conhecimento usado para chegar a uma dessas analogias que fazem a maior diferença. Também é o conhecimento usado para impressionar os outros. Você não precisa saber muito de comunicação de computadores para falar em rotedores, pacotes e protocolos.

Se tudo que você quer é ter assunto para conversar, conhecimento horizontal é o que você precisa. Para resolver problemas interessantes, é preciso conhecimento vertical. É preciso se aprofundar em algum nicho, se especializar.

Muitas tecnologias populares começam em pequenos nichos. São usadas por muito pouca gente no início, mas um dia alguém com visão resolve aplicá-las em um contexto diferente e a coisa explode. A Internet é um exemplo disso. Ela começou como forma de comunicação entre centros universitários e era usada também para troca de dados militares. No final da década de 80 e início dos anos 90, foi desenvolvida a base para a Web moderna e a partir daí a coisa explodiu. Claro que isso é uma simplificação da realidade (e o que não é?), mas ilustra o ponto de que um especialista que estuda um assunto a fundo pode ver oportunidades que os demais nunca vão imaginar.

Mas especialização demais também pode ser uma armadilha. Ela começa a ser perigosa à medida que se desiste do conhecimento horizontal pelo vertical. Fazer isso é desistir de idéias brilhantes ligando um campo do conhecimento ao outro. Especialização demais pode estreitar a visão a ponto de só permitir enxergar o próprio nariz.

Como (tentar) prever a criatividade

2006-10-18T23:16:00.000-07:00

Este é o primeiro artigo de uma série de três derivados de uma palestra apresentada na FAPE em outubro de 2006.

Previsibilidade é quase o oposto de criatividade. À primeira vista, podemos colocar criatividade e previsibilidade em dois extremos do mesmo eixo. Para aumentar uma, é preciso diminuir a outra.

No extremo da previsibilidade temos organizações que têm somente capacidade de repetição. Suas atividades são facilmente gerenciadas por serem extremamente previsíveis. Uma forma de alcançar este grau de previsibilidade é inventar sempre a mesma coisa. O problema é que repetir a mesma coisa várias vezes não é inventar. Por isso que esses lugares altamente previsíveis são extremamente chatos para se trabalhar. Você está sempre fazendo as mesmas coisas. Escrevendo o mesmo relatório para o mesmo gerente.

No lado extremo da previsibilidade, temos fábricas tradicionais, com linhas de montagem e tudo mais, como as que Henry Ford projetou. Nestas fábricas tudo é extremamente previsível. Se colocarmos uma peça no começo da linha, podemos saber com uma boa precisão quando ela passará por cada um dos estágios. Essa previsibilidade é alcançada através de muita padronização e repetição.

No outro extremo estão as organizações que escolheram abandonar totalmente a previsibilidade em favor da criatividade. Essas inventam coisas maravilhosamente interessantes, mas não se pode confiar muito nelas para estabelecer prazos. Você sabe que dali vai sair alguma coisa surpreendente, mas ninguém sabe dizer quando. Estes lugares também são muito chatos para se trabalhar, porque parece que nunca vão acabar de construir nada. Sempre há um último retoque para ser feito. Sempre aparece um novo projeto interessantíssimo para deixar o anterior inacabado.

É deste lado que ficam alguns artistas, como Leonardo da Vinci. Ele era conhecido por atrasar as encomendas e tem gente que diz que às vezes ele até colocava alguns significados ocultos nas telas. Fazer uma encomenda a ele era receita certa para uma boa dor de cabeça. Ele não ia entregar no prazo e no final o que ele entregasse podia não ser muito bem aquilo que você tinha pedido. No entanto, ninguém pode dizer que ele não era criativo. O cara era a inovação em pessoa, inclusive foi pioneiro em muitas áreas de pintura, engenharia e anatomia.

É natural perguntar quantos carros uma fábrica pode produzir por dia. Mas não faz sentido nenhum perguntar a nenhum pintor que se preze quantos quadros ele pode fazer por mês. Cada quadro é uma obra única e o tempo de produção pode variar demais para que estimativa seja minimamente precisa.

Nenhum dos dois extremos é bom. A boa notícia é que não precisamos escolher entre preto ou branco. Há vários tons de cinza entre eles que podemos explorar.

Ao contrário do que possa parecer, não precisamos escolher entre uma e outra. Previsibilidade e criatividade não estão no mesmo eixo. As duas são ortogonais. Não precisamos necessariamente diminuir uma para aumentar a outra. Não é preciso ser imprevisível para ser criativo. Talvez as variáveis não sejam tão independentes como queiramos, mas também não são tão intrincadas que não dê para separá-las um pouco.

A menos que você esteja querendo reconstruir alguma coisa que já tenha construído, desenvolver software é um processo criativo. Só que nem todo programador pode se dar ao luxo de fazer como Da Vinci e desrespeitar prazos e demandas. É preciso ter algum grau de previsibilidade para agradar os clientes.

Para lidar com este problema é que foi inventada a iteratividade. O segredo é projetar o software em ciclos curtos chamados de iterações. No início de cada iteração, a equipe combina com o cliente o que deverá ser produzido durante um certo período de tempo e ao final deste período o cliente recebe um sistema funcional que pode ser testado. Pode ser que o sistema seja bem pequeno, minúsculo. Mas ele evoluirá ao longo do tempo até chegar uma hora que o cliente diga 'está bom, era isso que eu queria' e os programadores possam procurar um novo projeto.

Uma boa forma de se enganar é não entregar software rodando ao final da iteração. Você pode, no lugar disso, entregar um calhamaço de documentos, só para provar que não ficou parado o tempo todo. A idéia é que quem quer que esteja pagando pela sua empreitada possa validar esses documentos e dizer 'continue, você está no rumo certo' ou 'não é bem por aqui, acho que devemos mudar de estratégia'.

Quando se usa um documento para esse tipo de comunicação, uma de três situações pode ocorrer. A primeira é o cliente validar seu documento e assinar embaixo, só que ele estava pensando em uma coisa quando leu e você estava pensando em outra bem diferente quando escreveu. A segunda é ele não concordar com o que você escreveu e implicar com as menores coisas para ter certeza que você entende o que ele está querendo. Essa segunda situação pode facilmente descambar para um fluxo eterno de remendos ao documento que impede que a coisa de verdade seja construída. A terceira possibilidade é que ele valide o que você escreveu e esteja pensando no mesmo que você. Mas é mais fácil ganhar na loteria do que isso acontencer.

Esse problema não acontece com software rodando. Quando o produto está vivo na frente do cliente, não há espaço para interpretações erradas. O sistema faz exatamente aquilo que está fazendo ali, ao vivo, na frente dele. Se algo estiver errado ou puder ser melhorado, o produto é um objeto concreto para servir de instrumento na discussão. Ninguém vai precisar adivinhar o que o outro está pensando.

A chave para o equilíbrio entre previsibilidade e criatividade através de iterações está em achar um tempo de iteração que seja pequeno o suficiente para que as estimativas não fiquem muito distorcidas e grande o suficiente para permitir que alguma coisa de útil seja feita. Tudo isto ainda permitindo que a equipe possa exercitar sua criatividade.

15 Mega de fama

2006-10-04T06:06:00.000-07:00

Grande idéia de Bill Seaver, blogueiro do Tennessee. Os quinze minutos de fama são passado. Hoje em dia 15 Mega de fama são muito mais comuns.

Anônimos de toda parte do mundo estão experimentando pequenos momentos de fama através da mídia digital. Quando todo mundo é especial, ninguém é especial.

Uma pequena grande idéia

2006-09-27T20:15:00.000-07:00

Qual é o padrão de projeto que você mais usa? Que pequena estrutura insiste em aparecer quase que espontaneamente no seu código?

Eu particularmente nunca cheguei a contar quantas vezes uso cada padrão, mas tem um que com certeza estaria bem no topo da lista dos mais usados se eu contasse. Dica: não é o Singleton. Também não é nenhum dos padrões do clássico GoF. É um padrão bem pequeno e localizado que às vezes é chamado de Null Object. Muito provavelmente você já deve conhecer ele, seja por este ou outro nome. Isso de nomes diferentes para os mesmo padrões acontece com freqüência, já que muitos deles brotam em vários locais, várias cabeças, diferentes de forma independente.

Suponha que você esteja construindo uma wiki como parte de uma ferramenta de acompanhamento de projetos. Somente usuários autenticados podem editar páginas nesta wiki. Isso pode ser resolvido com algo parecido com isso (Ruby):

1 def edit
    @page = find_page(params[:page_name])

    if current_user.nil? ||
5      !page.editors.include?(current_user.login)
      redirect_to :action => 'show',
                  :page_name = params[:page_name]
    end
  end

Mas aquela linha cinco está particularmente feia. Podemos esconder essa verificação num método bem nomeado na classe User.

1 class User
    def can_edit?(page)
      page.editors.include? self.login
    end
5 end

Ainda há bastante espaço para melhoria aqui. Esse trem de chamadas de método da linha três está bem grande e pode ser diminuído, mas vamos primeiro ver como ficou a nova definição de edit:

1 def edit
    @page = find_page(params[:page_name])

    if current_user.nil? ||
5      !current_user.can_edit?(@page)
      redirect_to :action => 'show',
                  :page_name = params[:page_name]
    end
  end

Já melhorou bastante, mas aquela verificação de nulidade que ficou na linha quatro ainda está me incomodando. Há tantos detalhes embutidos nesta pequena chamada current_user.nil? que podem fazer a cabeça de alguém explodir. Para entender isso é preciso saber que current_user é igual a nil quando o usuário não está autenticado. Além disso, a regra que diz que os usuários devem estar autenticados e autorizados a editar a página está toda codificada nesta pequena linha de código. É responsabilidade demais para uma única linha.

Eu não quero ser responsável pela explosão de nenhuma cabeça, portanto vou procurar algum modo de melhorar isto. Seria melhor se pudéssemos dizer somente current_user.can_edit?(@page), mas não podemos fazer isso porque o objeto nil (sim, nil, assim como qualquer coisa em Ruby, também é um objeto) que representa o usuário não autenticado não responde ao método can_edit?. Por isso precisamos de todo esse tratamento desajeitado para o caso especial.

Mas o usuário não autenticado não precisa ser representado por nil. Ao invés disso, podemos definir uma nova classe chamada UnidentifiedUser que é um Null Object. Ela vai ser uma classe bem pequena, usada simplesmente para tratar o caso especial do usuário não autenticado. Os detalhes sobre tratamento de usuários sem autenticação vão ficar confinados a ela e o restante do sistema poderá tratar todos os usuários uniformemente. Segue o código:

1 class UnidentifiedUser
    def can_edit?(page)
      false
    end
5 end

E acabou. O usuário não identificado só precisa responder que não pode editar nenhuma página, sem exceção. Como isto aqui é Ruby, não precisamos dizer que esta classe herda da User original porque usamos duck typing. Se estivéssemos usando uma linguagem estaticamente tipada, precisaríamos disso (como vamos ver no próximo exemplo que usa Java).

Isso é tudo que precisamos para esta classe, mas ainda precisamos alterar o método current_user, para que retorne um objeto UnidentifiedUser ao invés de nil no caso do usuário não estar autenticado.

1 def current_user
    session[:user] || UnidentifiedUser.new
3 end

Outra forma de alcançar o mesmo efeito é injetar o método can_edit? diretamente no objeto nil, já que Ruby não diferencia tempo de compilação, linkagem e execução. Desse modo não precisamos nem modificar este último método.

Este pequeno padrão se mostra muito útil. Suponha agora que você esteja escrevendo um IDE para alguma linguagem extremamente bela que quase ninguém usa por achar diferente e esquisita. Este seu IDE usa um compilador externo por baixo dos panos e o programador pode escolher se quer ver a saída do compilador. Vamos começar pelo código feio e passar lentamente para uma versão mais elegante. Claro que isso é só minha opinião. Mas este é o meu blog, tudo aqui é só minha opinião. (Java)

1 class Compiler {
  
     // ...
  
5    void compile(IFile target) {
         if (compilerOutputEnabled())
             output.write(
                 "Starting compilation from file "
               + target.getName());
10
         String cmdLine = "ghc --make " + 
             target.getFullPath().toOSString();

         if (compilerOutputEnabled())
15           output.write(cmdLine);

         String output = processRunner.execute(
             sourceFolderFor(target), cmdLine);
20       
         if (compilerOutputEnabled())
             output.write(output);
     }

25}

Eu avisei que iríamos começar pelo código feio... Você também está sentindo o mau cheiro? Essas linhas repetidas perguntando se alguma coisa deve ser relatada não estão te dando coceira? Vamos tratar isso antes que comecem a estourar bolhas.

O objeto output apareceu magicamente para este nosso método. Estamos assumindo que ele foi inicializado pelo nosso Compiler em algum ponto omitido do código. Mas não precisa ser assim. Podemos injetar qualquer Writer se o output for um parâmetro do método.

Vamos escrever então um Writer especial que sabe quando deve escrever de verdade ou não e injeta-lo no método compile por passagem de parâmetro.

1 public CompilerOutputWriter extends Writer {

      // ....

5     @Override
      public void write(char[] cbuf,
          int off, int len)
      {
          if (compilerOutputEnabled()) {
              underlyingWriter.write(
                  cbuf, off, len);
          }
10    }
  }

A responsabilidade de checar se a saída deve ser mostrada agora passou para o objeto CompilerOutputWriter. Podemos tirar as checagens do método compile:

1 class Compiler {
  
     // ...
  
5    void compile(IFile target, Writer output) {
         output.write(
                 "Starting compilation from file "
               + target.getName());

10       String cmdLine = "ghc --make " + 
             target.getFullPath().toOSString();

         output.write(cmdLine);

15       String output = processRunner.execute(
             sourceFolderFor(target), cmdLine);
       
         output.write(output);
20   }

  }

O código está ficando melhor, mas ainda dá pra deixá-lo mais apresentável. Podemos apagar a classe CompilerOutputWriter por inteiro (você também tem uma ótima sensação quando apaga código?) e introduzir um NullObject que será selecionado quando a saída do compilador for desabilitada. Por exemplo:

1 public class NullWriter extends Writer {

      // ....

5     @Override
      public void write(char[] cbuf,
                        int off, int len)
      { /* ignore */ }

  }

Um NullWriter simplesmente ignora a entrada. O pobre compilador vai achar que está escrevendo alguma coisa, mas qualquer coisa que ele pedir será ignorada. Agora a responsabilidade de saber se o usuário quer ou não ver a saída do compilador é de quem está chamando o Compiler, e ele tem todo o direito de delegar a responsabilidade.

O padrão NullObject é uma forma de tratar casos especiais que substitui a lógica condicional por uma solução mais limpa. Por falar nisso, parece que eliminar lógica condicional é uma Boa Idéia™.

A linguagem independente de linguagem

2006-09-21T16:36:00.000-07:00

A palavra de hoje é modelagem. Quando os programadores ouvem esta palavra, não pensam em porcelana, argila ou massa de modelar. Eles imaginam diagramas, esquemas, retângulos, setas e coisas do tipo. Bem estranho, mas é verdade. O que os programadores chamam de modelagem não passa de uma forma de expressão que usa uma linguagem visual ao invés de uma escrita. Se os esquemas fossem quadros, o código-fonte seria um poema. São artes diferentes e têm públicos diferentes. Do mesmo modo que há gente que consegue apreciar melhor um poema do que um quadro, tem gente que entende melhor código-fonte do que esquemas. Diferentemente do que acontece nas artes, os esquemas e diagramas dos programadores podem ser usados para gerar código-fonte sem nenhuma intervenção humana. Dependendo da tecnologia em uso, este código precisa ser lapidado manualmente para que possa ser finalmente executado por um computador. Pessoas diferentes conhecem linguagens de programação diferentes, por isso alguém teve a idéia de usar os diagramas para permitir liberdade na escolha das linguagens textuais. Usar uma linguagem visual pode ser uma boa idéia, mas não para obter independência de linguagem. Esse objetivo de escrever (ou deveria dizer desenhar?) um programa de forma independente de linguagem é simplesmente inviável. Nunca chegaremos lá, simplesmente porque não dá para projetar nada sem uma linguagem, uma representação, específica. Se você vai escrever alguma coisa, precisa escolher uma linguagem qualquer e, por definição, não existe isso de linguagem independente de linguagem. O que podemos fazer é desenvolver linguagens cada vez de mais alto nível que poderão ser traduzidas para diversas outras de baixo nível. Quando finalmente conseguirmos ficar livres das linguagens de base, vamos descobrir que estamos presos à mais abstrata. Ela pode ser mais produtiva, intuitiva e todo o resto que você queira imaginar, mas ainda é uma linguagem. Isto não é ruim. O propósito de usar linguagens visuais não é poder trocar a linguagem de suporte. De preferência, não devia nem haver uma representação textual intermediária que precise de ajustes manuais. Na Terra dos Modeladores Felizes, diagramas são executáveis do mesmo modo que um conjunto de instruções de máquina. A verdadeira razão de haver linguagens visuais é que algumas pessoas acreditam que elas são mais abstratas e produtivas. Abstração é causa direta da produtividade. A segunda não vem sem a primeira. Não adianta usar uma linguagem visual se ela possui exatamente as mesmas construções de alguma outra textual. Se ela puder ser traduzida para a forma textual com uma correspondência direta, não há ganho de produtividade. Na verdade, é bem provável que haja perda. O ponto é que programadores passam muito pouco tempo realmente digitando (ou desenhando). A parte mais difícil e trabalhosa é feita dentro da cabeça. Acelerar a edição é se concentrar no problema errado. O que queremos mesmo é maior expressividade. Isto pode muito bem vir de uma linguagem visual. Ou não. Afinal, não é qualquer imagem que vale mais do que mil palavras.

Erros de programação não existem...

2006-09-12T22:38:00.000-07:00

...isso é coisa da sua imaginação.

Às vezes — e aqui sempre não seria uma aproximação tão grosseira — quem desenvolve um programa não sabe exatamente em que sistema ele será usado. É fácil ter uma ligeira idéia, mas há usuários demais para que seja possível ter certeza. Você já deve ter ouvido slogans do tipo "Escreva uma vez, rode em qualquer lugar", mas isso é só propaganda. Claro que uma plataforma comum dá alguma segurança e aumenta a produtividade. Mas se você quer saber exatamente como seu programa se comporta nas mais variadas configurações, você precisa testá-lo. Não tem jeito. Você precisa soltar o coitado neste lugar inóspito que é o mundo real e ver como ele se sai. Pode parecer injusto, mas é para o bem dele.

Os usuários esperam que as coisas Simplesmente Funcionem ™ e saber o que eles esperam é um trabalho de requisitos e testes, não de programação. Isto não quer dizer que programadores não devam fazer isso, mas que as habilidades que eles devem ter vão além de escrever código. Isto envolve muito condicionamento, bastante experiência e um bocado de imaginação. Mas se um programa não funciona do modo esperado em alguma situação, ele não está errado. Se eu não programar o EclipseFP para saber que alguns módulos poderão ser importados de outra parte do mundo fora do meu controle, se seu formulário não estiver preparado para o espertinho que escreve os números por extenso ou se Joel Spolsky não previr que na Polônia o Alt-Direito é usado para digitar caracteres especiais, não quer dizer que nossos programas estejam incorretos. Eles estão corretos para algumas das possíveis situações.

Todo programa é escrito e testado com algum uso em mente. Mesmo que os testes não sejam escritos em linguagem de computador, todo mundo testa o que escreve pelo menos uma vez de forma manual. Obviamente estou simplificando um pouco as coisas aqui. Afinal existe gente que escreve programas e não precisa (ou não quer) se dar ao luxo (ou à sanidade) de executá-los antes da entrega. Mas, por favor, vamos desconsiderar esses prodígios (ou azarados) pelo bem do argumento. Se o código for executado e validado várias vezes de forma automática à medida que evolui, a chance de que deixe de funcionar diminui. Mas o fato é que, mesmo se você estiver escrevendo testes automáticos como deveria, eles não cobrem todas as situações. Eles não conseguem fazer isso. É simplesmente impossível porque o espaço de busca é potencialmente infinito.

Testes não podem garantir que um programa nunca vai se comportar de forma inesperada. Nada pode. Se seu programa for usado por uma variedade razoável de pessoas, alguém em algum lugar do mundo vai ter a chance de dizer "como diabos eles não pensaram nisso?". Tudo que você pode fazer, se você tiver cuidado e reservar bastante tempo para pesquisa e testes, é garantir que quem vá dizer isso esteja em um lugar bastante remoto. Mas vai haver alguém. Sempre.

Erros de programação — diferentemente de fantasmas, lobisomens e sacis — não existem. O que existe mesmo são situações não previstas e testes que ainda não foram escritos.

O que é um programa?

2006-09-04T19:44:00.000-07:00

Todo mundo é capaz de escrever um programa de computador. Até crianças de dez anos. Lembro que quando eu tinha essa idade, as aulas de informática na minha escola giravam em torno de uma tartaruga que desenhava algumas formas geométricas. Para isso, era preciso dar comandos a ela utilizando a linguagem de programação Logo (que pode ser experimentada utilizando o interpretador KTurtle, entre outros). Eu não posso dizer que gostava das aulas, mas o exemplo mostra que crianças também podem escrever programas.

Depois daquelas aulas de informática já escrevi alguns outros programas. Mas o que diabos é isto?

Esta página HTML que você está lendo é um programa? O editor que eu uso para escrevê-la (outra página HTML) é um programa? O navegador que você está usando para passear pela Internet é um programa? Um desenho gravado em formato bitmap é uma programa? E se o formato for vetorial?

Você já deve ter visto em algum shopping center aquelas máquinas que fazem desenhos bordados. Elas desenham a partir de padrões armazenados em meio eletrônico e há empresas especializadas em produzir estes padrões. Uma dessas empresas estava processando um de seus clientes por ter alugado cartuchos onde estavam armazenados os padrões e, recentemente, o tribunal considerou-os como dados e não como programas.

Pela lei deles, é permitida a troca de meios de armazenamento que contenham dados sob direitos autorais, desde que estes dados não sejam programas. Se alguém adquire legalmente dados e grava-os em algum meio físico (como um CD ou pen drive), ele tem permissão para vender, alugar ou doar este meio juntamente com os dados (mas não tem permissão para fazer outras cópias). Entretanto, se estes dados forem programas de computador, a transferência não pode ser feita. Portanto, se alguém entra em uma loja e compra um disco onde está gravado um programa, o disco a princípio é intransferível e não pode ser emprestado a mais ninguém.

A empresa da nossa história queria que seus padrões de bordado fossem considerados programas de computador. Assim o seu cliente estaria violando a lei ao ter alugado sua cópia para outros e muito provavelmente teria que pagar uma multa bem gorda.

Todo dado interpretado por computador é escrito em alguma linguagem projetada por alguém. Pode ser que o projetista da linguagem nem saiba que está projetando uma linguagem, mas nem por isso deixa de estar. HTML, por exemplo, é uma linguagem e seus projetistas sabiam disso. Sabiam tanto que colocaram este L no final que é justamente a inicial de Linguagem. O formato de imagem JPEG também é uma linguagem. Não é muito tratado como tal, mas também é uma linguagem. Há máquinas (muitas vezes simples programas de computador) capazes de ler e interpretar dados escritos nessas linguagens. Interpretar aqui pode ser mostrar uma saída para alguma pessoa. Exatamente o que está acontecendo agora para você ler estas palavras.

Um subconjunto bastante interessante de todas estas linguagens que a mente humana pode imaginar é o das linguagens Turing-completas. Se você cursou algum curso de computação e não matou nenhuma aula (o que, admito, é praticamente impossível para um ser humano), deve saber que estas são linguagens com poder computacional equivalente ao de uma máquina de Turing, um modelo teórico que pode ser usado para descrever até mesmo este computador de última geração que você tem aí. Qualquer linguagem de programação que se preze é Turing-completa. Na verdade, eu acho que uma linguagem precisa ser Turing-completa para ser chamada de linguagem de programação.

Para estas linguagens especiais, também é possível construir máquinas de interpretação e programas seriam simplesmente dados escritos em uma dessas linguagens.. Interpretar aqui pode ser visto como traduzir o programa para uma outra linguagem que será novamente traduzida e que, no fim das contas, gera uma saída para alguém. Exatamente o que está acontecendo agora pra você ler estas palavras.

Mas e se os padrões de bordado fossem escritos em Ruby, Java ou Haskell? Eles seriam programas?

É perfeitamente possível desenvolver uma máquina de bordar que entendesse uma dessas linguagens. Seria mais fácil ainda construir uma máquina capaz de interpretar um subconjunto dessas linguagens. Para um programador humano, os padrões pareceriam claramente com o que chamamos de programa, mas para a máquina seriam diretamente equivalentes aos dados no formato inicial.

A diferença entre dados puros e programas não está nos dados, mas na máquina que os interpreta. O intrigante é que, do ponto de vista das máquinas (se é que máquinas têm ponto de vista), os programas não passam de dados.

Protagonistas e coadjuvantes

2006-08-17T13:35:00.000-07:00

Em filmes, novelas, livros e em qualquer outro meio que se conte uma estória, há personagens protagonistas e coadjuvantes. Estes últimos desaparecem em meio aos primeiros. Ninguém nota que eles estão lá, mas todos notam algo esquisito se eles não estiverem.

Do mesmo modo, os famigerados "processos de desenvolvimento de software" podem ganhar muito se forem tão naturais que nem se note sua presença. Eles podem funcionar como figurantes de um filme: são essenciais para que tudo corra agradavelmente, mas não prendem a atenção de ninguém. Na verdade, eles estão lá justamente para não chamar a atenção. Quanto mais apropriado o processo estiver para a realidade da equipe, mais as pessoas vão achá-lo natural e mais ele será confundido com o cenário.

Sob esta ótica, uma equipe com o conjunto de práticas ideal vai achar que não há nada além de pessoas trabalhando. Nada de processos ou metodologias.

Melhor que a encomenda

2006-08-15T14:30:00.000-07:00

Fazer somente o solicitado pode ser um suicídio completo em qualquer mercado competitivo e, a menos que você detenha algum tipo de monopólio, desenvolvimento de software é um desses mercados. Seus concorrentes muito provavelmente estão fazendo mais do que o estritamente necessário e ninguém quer ficar para trás. O inverso, entretanto, não é receita de sucesso. Fazer mais do que o requisitado pode levar a uma corrida sem fim por novas funcionalidades que vai drenar toda a energia da sua equipe e deixar muita coisa inacabada.

Se você tem uma capacidade de produção limitada (e quem não tem?), é melhor evitar corridas tresloucadas e tentar se destacar no essencial. Fazer menos coisas para que possa fazê-las com mais qualidade.

Acho que este é o exemplo mais batido da Internet hoje em dia (se bem que o iPod está se mostrando um adversário à altura), mas vou usá-lo assim mesmo. No ano 2000, enquanto um de seus maiores concorrentes, o Yahoo, tinha uma página repleta de links e funções, o Google (o sistema de busca, não a empresa) tinham apenas um campo de texto e um botão. Eles tinham uma única coisa para fazer, por isso podiam se concentrar. O resultado é que conseguiram se destacar, apesar dos concorrentes oferecerem mais serviços à época. Você sabe o que é um sucesso, quando uma marca começa a virar verbo. Hoje em dia eles já estão brigando para que a marca não passe para domínio público como sinônimo de busca.

Introduzir novos serviços não solicitados é um jogo de adivinhação e, a menos que você esteja no ramo da clarividência, este não é o tipo de jogo que você quer jogar. Por outro lado, fazer melhor do que o esperado pode colocar você no mesmo pedestal do "mais", mas sem o risco associado.

Acho que a moral da história dessa vez é: faça melhor que a encomenda, não mais que a encomenda.

Testes e especificações

2006-08-11T07:23:00.000-07:00

Linguagens são umas criaturas muito flexíveis. As melhores linguagens de programação são as mais maleáveis, aquelas que permitem ao programador moldá-las às necessidades da sua aplicação. Quem usa a biblioteca de testes JUnit em Java, faz scripts de build com Rake em Ruby ou usa o Monad IO em Haskell praticamente não pensa nas primitivas da linguagem. Ao invés disso, a mente passeia pelos termos próprios ao domínio da aplicação. Não se pensa em classes, objetos, métodos e funções, mas em casos de teste, tarefas e comandos.

As linguagens naturais não são diferentes, estão o tempo todo mudando. Basta um grupo de pessoas se comunicando para que jargões e dialetos comecem a se formar. Novas palavras surgem e outras saem de moda com uma velocidade surpreendente. Há oito anos atrás, por exemplo, se a palavra "agilidade" fosse citada em uma conferência de desenvolvedores de software, poderia muito facilmente ser associada a soluções rápidas e sujas. Hoje para muita gente é sinônimo de alta iteratividade, valorização do feedback e adaptação constante. Parece mais com rápido e limpo do que com outra coisa qualquer.

Para que algumas palavras mudem de sentido, basta que sejam usadas por duas pessoas diferentes. "Especificação" é uma dessas famigeradas palavras com muitos significados. Muita gente presume que uma especificação é completa, ou seja, que prevê as saídas para todas as entradas possíveis. Por outro lado, outras tantas pessoas presumem apenas que uma especificação é não-ambígua, isto é, pode ser interpretada de um único modo.

Entretanto, a maioria das pessoas — e isto inclui programadores e seus clientes — não conseguem fazer especificações de nenhum desses dois tipos. Pelo menos não naturalmente. Não sem conscientemente se obrigar a isso. Estas especificações acabam saindo tanto ambíguas quanto incompletas. Seria bom que tivéssemos algum tipo de máquina capaz de garantir pelo menos uma dessas duas propriedades.

O que não é muito difícil de se achar...

Computadores são máquinas construídas exclusivamente para seguir instruções. Eles não podem interpretar a mesma instrução de dois modos diferentes. Podemos então escrever nossas especificações como um programa de computador e só vai haver um modo de interpretá-las. Assim eliminamos a ambigüidade e ainda ganhamos a habilidade de executar tudo automaticamente. Só que o nome "especificação" é um tanto quanto controverso, é melhor chamar estes programas somente de testes. Testes são executáveis. Podem não ser especificações, mas são executáveis.

Para executá-los basta fornecê-los ao computador adequado e eles vão rodar rapidamente. Muito mais rápido do que alguém poderia fazer manualmente. Programadores são especialmente bons em generalizar o comportamento esperado do sistema a partir de um conjunto de entradas. Se escrevermos testes para os casos excepcionais, podemos ficar razoavelmente seguros que o código está completo. Caso não esteja, quase sempre podemos encontrar mais testes. Esta segurança é somente estatística, pois é impossível testar todas as entradas na prática, mas é muito mais segurança do que se tem com uma linguagem natural.

Moral da estória: não dá para especificar tudo com testes automáticos, mas dá para especificar muita coisa.

Esqueletos, apêndices e fantasmas

2006-08-07T22:13:00.000-07:00

Então vocês finalmente conseguiram um cliente. Ele está muito empolgado e tem muitas expectativas para o projeto. Naturalmente, vocês também têm. Por onde começar?

Nesse início de projeto é óbvio que todo mundo está cheio de idéias, tanto vocês quanto o cliente. Todo mundo quer colocar todas as idéias em prática, mas há um limite para o que vocês conseguem entregar. A questão do que fazer primeiro é vital.

Uma idéia é levantar alguns requisitos iniciais com o cliente e escolher as funcionalidades mais representativas do ponto de vista técnico. Ainda não é preciso saber tudo que ele vai querer, somente o suficiente para ter uma idéia geral. Desse modo pode-se montar um esqueleto inicial do sistema sobre o qual as funcionalidades futuras se apoiarão.

Esta não é necessariamente uma boa idéia.

Pelo menos não é desse jeito que os esqueletos vêm tradicionalmente sendo desenvolvidos. Os esqueletos humanos, por exemplo, são produto de alguns milhares de anos de mutação e seleção natural. Não ganhamos este esqueleto que temos hoje de uma hora para a outra, foram necessárias várias gerações e muito refinamento do projeto inicial. Assim como na natureza, é melhor que a estrutura básica de uma aplicação evolua a partir de um conjunto mínimo ao longo do tempo ao invés de ser inventado tentando prever o futuro. Programadores não são muito bons em prever o futuro, então é melhor evitar projetar coisas que não precisaremos e deixar os apêndices evolucionários que ocasionalmente surgirão desaparecer naturalmente.

Mas há um argumento ainda mais forte. Quando levantamos prioridades observando apenas o mérito técnico, ignoramos o valor de negócio. Pode ser que as funções com maior representatividade técnica coincidam com as funções de maior valor para o cliente. Mas isto em geral não acontece. O resultado de priorizar inicialmente o desenvolvimento de um esqueleto normalmente são projetos que iniciam com uma grande fase de infra-estrutura e que, durante este tempo, não atendem a nenhuma necessidade do cliente.

O lado oposto desta idéia é deixar o cliente completamente livre para ordenar as funcionalidades como ele queira. Nesta abordagem tudo se inverte. Ao invés da aplicação se adaptar à infra-estrutura inicial, é a infra-estrutura que vai se adaptando às necessidades da aplicação. Os clientes podem então escolher em que investir.

São eles que estão pagando a conta, é natural deixá-los escolher em que investir. Claro que o papel dos programadores, especialistas em desenvolvimento de software, é mantê-los informados sobre suas opções. Eles podem oferecer seu conhecimento — devem fazer isso — mas a decisão final é dos clientes. Escolher uma funcionalidade ao invés de outra com base somente em quesitos técnicos é privá-los desta decisão.

Desastre na Torre de Babel

2006-08-01T12:21:00.000-07:00

Essa nossa língua portuguesa é extremamente e rica e ainda mais extremamente incompreendida. Dia desses descobri uma ótima discussão em pelo menos dois blogs sobre o termo padrão de projeto, tradução já consagrada de design pattern. Os dois parecem concordar que a tradução tradicional tem atrapalhado a indústria brasileira porque as pessoas entendem "padrão" como "norma". A palavra é realmente ambígua, mas com certeza não é a raiz da questão. A grande prova é que o problema não acontece somente aqui.

É verdade que é bem fácil encontrar no Brasil organizações que promovam uma "arquitetura" normatizada, independentemente do domínio do problema ou do contexto do projeto. Essas organizações realmente parecem gostar de dizer que têm uma "arquitetura" baseada em padrões de projeto. Aliás, a palavra "arquitetura" devia sempre vir envolvida em aspas, já que tem tantos sentidos para tanta gente diferente.

É verdade que é bem fácil encontrar alguns brasileiros integrando a gangue dos padrões. Você já conheceu pelo menos um destes: eles acabaram de sair da faculdade (ou em muitos casos, ainda estão lá) e acham que os padrões de projeto podem resolver todos os problemas do mundo, da guerra no Líbano ao açúcar do cafezinho.

Também é verdade que os brasileiros abusam do padrão Singleton. Mas todos estes problemas acontecem com a mesma freqüência no resto do mundo.

Desde o dia em que aqueles quatro caras popularmente conhecidos por Gang of Four (ou pelo acrônimo GoF) publicaram o Design Patterns: Elements of Reusable Object-Oriented Software (que aliás, é um ótimo livro: se você não leu ainda, corra para ler), as pessoas têm usado mal o padrão Singleton. Esta famigerada criatura não passa de uma variável global vitaminada e a primeira pessoa que abusou do coitado muito provavelmente não o conheceu por litetatura em português. Afinal, os termos foram cunhados originalmente em inglês.

Acontece que o Singleton é especialmente útil para quem tem a mente acostumada com o pensamento imperativo. Ele permite agrupar um conjunto de funções em algo parecido com um objeto e dizer que se usa programação orientada a objetos. É um dos modos mais fáceis de estar na moda (tanto na moda dos objetos quanto na dos padrões) e foi o que muita gente escolheu.

O problema é que algumas pessoas pegaram a febre dos padrões e começaram a vê-los como normas, quase leis, e entraram numa cruzada insana pelo Santo Graal dos padrões. Só precisamos encontrar a cura e o meu palpite é que ela vai levar uma boa dose do bom e velho senso crítico.

Como uma maçã boa é estragada pelas demais

2006-07-18T20:03:00.000-07:00

Vamos supor que você é diretor de uma empresa que desenvolve software. Você tem acompanhado toda essa literatura moderna sobre equipes auto-organizadas, métodos ágeis e coisas do tipo. Na sua empresa há quinze programadores efetivos que precisam ser distribuídos em três equipes para três projetos de igual importância. Destes quinze você classificaria quatro como brilhantes e agradece a todos os deuses que eles estão trabalhando com você e não com os concorrentes. Outros três estão um pouco abaixo da média e do restante do pessoal você não tem muito do que se queixar. A questão é: como organizar as equipes?

O melhor a se fazer é distribuir os seus astros e estrelas cada um em uma equipe, dar a eles um título diferente dos demais e fazê-los se ocupar de analisar o problema enquanto os outros cuidam do trabalho sujo, certo?

Errado. Isto era antes da era da auto-organização. Você acredita que projetar software é um trabalho criativo e, para trabalhos criativos, equipes com a liberdade de se auto-organizar são mais produtivas que as equipes baseadas em comando e cobrança. Então você faz tudo do jeito anterior, só que toma o cuidado para não dar títulos às pessoas e deixá-las escolher as próprias responsabilidades. Assim a equipe vai convergir naturalmente para a configuração de maior produtividade, certo?

Errado novamente. Psicólogos descobriram que em organizações sem hierarquia muito rígida as pessoas mais fracas tendem a se unir para atacar e expulsar as de maior destaque. Então é bastante provável que ao invés dos melhores jogadores se tornarem líderes naturalmente, eles acabem sendo fagocitados do grupo. Eles são consciente ou inconsciemente excluídos pelo simples fato de serem melhores.

Ninguém quer que suas estrelas sejam eliminadas pelos colegas. Elas deveriam estar lá para brilhar e liderar, não para serem atacadas. No entanto, parece que é isso que acontece. Pelo menos se acreditarmos nos psicólogos.

A solução mais óbvia então é separar as equipes por nível de habilidade e manter as pessoas de nível similar juntas. Talvez seja melhor, ao invés de distribuir as melhores cabeças, mantê-las juntas e distribuir os jogadores mais fracos. Assim eles vão poder aprender com os colegas e crescer.

A não ser que os psicólogos descubram que uma maçã podre estraga as demais.

EclipseFP 0.10 disponível

2006-07-06T05:43:00.000-07:00

Demorou mas saiu. A versão 0.10 do ambiente de desenvolvimento Haskell EclipseFP está disponível para download desde a última sexta-feira (dia 30 de junho). O modo mais fácil de instalar o plugin (na minha opinião, claro) é utilizar o gerenciador de atualizações do Eclipse. Mais detalhes sobre download e instalação na página de downloads do projeto.

Para este release eu estive trabalhando principalmente em complementação de código, uma funcionalidade que tem sido muito requisitada desde a 0.9.1. Outro destaque é o editor para arquivos Cabal, contribuído por Leif Frenzel, que deve ser muito util para o próximo release, que deve incluir suporte para montagem e empacotamento com Cabal.

Esta versão exige uma plataforma Eclipse versão 3.2, diferentemente da versão anterior que rodava sobre Eclipse 3.1. É necessário atualizar sua plataforma para obter todos os benefícios do plugin. Isso não deve ser grande sacrifício, afinal você já deveria querer atualizar sua plataforma para aproveitar as correções de bugs e novas funcionalidades do Eclipse.

A última palavra em rastreabilidade

2006-06-30T04:42:00.000-07:00

A versão 0.5 do Motiro vai incluir um meio de acompanhar funcionalidades: saber o que entra no próximo release, o que fica de fora e votar no que você acha mais importante. Isso é bom para as equipes, que vão conhecer a vontade dos usuários e priorizar seu trabalho de acordo. Também é bom para os usuários, que vão saber o que esperar da evolução da aplicação e, melhor ainda, influenciar nesta evolução.

O Motiro já tem um pouco de integração com sistemas de controle de versão e, por isso, tive a grande idéia: prover algum meio de ligar um trecho de código à funcionalidade correspondente ("Este código aqui é para realizar a tradução da página"). Com isso poderíamos rastrear trechos de código para requisitos de usuário e vice-versa.

Acontece que minha idéia não é tão boa assim.

Na verdade, eu até diria que é uma má idéia. Fazer rastreamento desse jeito é jogar trabalho fora. Rastreabilidade é uma coisa ótima, mas acontece que no Motiro já usamos o que há de mais novo em termos de rastreabilidade.

Não, não temos nenhuma arma secreta escondida que não esteja publicada no site do projeto ou no próprio código fonte. Não usamos nenhuma ferramenta complicada, não desenhamos nenhum diagrama e muito menos mantemos uma matriz potencialmente gigantesca.

Não temos nada disso. Mas o Motiro é testado.

Nenhuma funcionalidade é desenvolvida e nenhum defeito é corrigido sem o teste correspondente. Portanto, para todo requisito há pelo menos um teste e descobri-lo é fácil, tão fácil quanto olhar seu título. Se quero saber que trecho de código implementa uma funcionalidade qualquer, é só olhar que trecho de código é executado pelo teste correspondente. Se quero saber por que alguma linha foi escrita, basta apagá-la e ver que teste falha.

Essa abordagem para rastreamento, ao contrário das outras que citei, não exige nenhum esforço extra por parte da equipe de desenvolvimento. Afinal, qualquer equipe que esteja realmente interessada em produzir software de qualidade vai ter algum mecanismo automático para verificação. Na maioria dos casos esse mecanismo é um conjunto de testes automáticos.

Os objetos estão te matando?

2006-06-23T10:19:00.000-07:00

Ou é você quem acha que a culpa é deles?

Hoje eu achei um exemplo de código ruim atribuído ao uso de objetos. O interessante é que se você olhar bem, o código na verdade é procedural. Só porque você está usando uma linguagem ou biblioteca com suporte a orientação a objetos, não quer dizer que você esteja programando orientado a objetos. Este é um engano bastante comum. Você já deve ter conhecido algum sistema por aí que parece ter sido construído sobre duas exigências básicas:

1. Usarás uma linguagem orientada a objetos
2. Escreverás somente código procedural

Dava até pra colocar numa tábua de mandamentos.

O objetivo do código do exemplo de Jeff Attwood que disparou este artigo é renderizar um trecho de XML. Vamos dar uma olhada:

1   System.Text.StringBuilder sb =
      new System.Text.StringBuilder();

    XmlWriterSettings xs = new XmlWriterSettings();
    xs.ConformanceLevel =
      ConformanceLevel.Fragment;
5   xs.Indent = true;

    XmlWriter xw = XmlWriter.Create(sb, xs);
    xw.WriteStartElement("status");
    xw.WriteAttributeString("code", "1");
10  xw.WriteEndElement();
    xw.WriteStartElement("data");
    xw.WriteStartElement("usergroup");
    xw.WriteAttributeString("id", "usr");
    xw.WriteEndElement();
15  xw.WriteEndElement();
    xw.Flush();
17  return sb.ToString();

Este trecho de código é totalmente procedural, e foi escrito usando uma linguagem e uma biblioteca de objetos (acho que isso é C# junto com alguma biblioteca .Net para XML). A grande estrela desse código é o objeto conhecido por 'xw'. Ele aqui está sendo usado como um elemento passivo, mero cumpridor de ordens. Tudo que ele precisa fazer é explicitamente requisitado:

— Xw, comece a escrever um elemento 'status'.
— Sim, senhor!
— Xw, escreva um atributo chamado 'code' com valor '1'.
— Sim, senhor!
— Xw, está bom, pode fechar este elemento.
— Sim, senhor!

... e assim por diante. Dar ordem expressas assim é característica de código procedural, que se confunde com o código imperativo. E código imperativo tem esse nome justamente porque é estruturado ao redor de um conjunto de comandos (ou ordens) básicos.

Esse tipo de argumento anti-objetos parece acontecer muito mais por causa da interface de uma biblioteca do que pelo uso de objetos. Bibliotecas diferentes vão ter interfaces diferentes. Este trecho de código Ruby enviado por um leitor do blog dele exemplifica bem:

  builder = Builder::XmlMarkup.new(:target=>STDOUT,
                                   :indent=>2)
  builder.person { |p|
     p.name("Jim")
     p.phone("555-1234")
  }

Aqui o estilo é muito mais declarativo. Quase idêntico a escrever o código XML você mesmo, mas sem os perigos de se tentar escrever manualmente em uma linguagem feita para máquinas.

A questão aqui não é a dicotomia orientado-a-objetos x procedural. Talvez isso nem exista. Como o exemplo em C# mostra, é possível escrever código procedural orientado a objetos. Além de possível, é bastante comum. A discussão na verdade é entre os estilos declarativo e procedural.

Quem será que ganha essa última?

Testando os testes

2006-06-20T13:32:00.000-07:00

"Ter testes automáticos para validar o código é muito bom. Você pode refatorar o código livremente, os testes te ajudam a saber que você não quebrou nada e bla bla bla."

Você muito provavelmente já escutou essa conversa. Esse é o discurso padrão dos xispistas e de quase todo mundo na comunidade ágil. Todo mundo fala que os testes servem para manter a aplicação saudável, mas o código dos testes também é código e ele precisará ser refatorado mais cedo ou mais tarde. Já aprendemos que não dá pra acertar da primeira vez no código de produção, achar que no de teste dá seria ingenuidade.

Já que não dá, fazemos com os testes o mesmo que fazemos com a aplicação. Escrevemos um pouco de cada vez e refatoramos conforme necessário para não repetir idéias, minimizar o acoplamento e alcançar todas aquelas outras coisas boas que aprendemos na escola (ou que a experiência nos ensinou).

Quando estamos refatorando o código da aplicação, confiamos no código de teste para não nos deixar cair. Mas quando é o código de teste que estamos refatorando não há uma segunda rede protetora, não há testes que testem os testes que testam o que deve ser testado (eu sei que ficou confuso, foi de propósito). Na verdade, podemos ir em frente e escrever os meta-testes.

Mas talvez não precisemos.

Os testes não estão tão desprotegidos assim. Há a aplicação para garantir que eles não estão fazendo nada errado. Ela foi escrita especialmente para passar naqueles testes e pode ser usada para garantir que o comportamento deles não está mudando, que eles estão checando o que checavam anteriormente. Se não alterarmos o código da aplicação quando estivermos reestruturando o dos testes, sair de uma barra verde para outra é razoavelmente seguro.

Há uma sinergia muito grande entre os dois tipos de código. O código de teste segura o de produção e o código de produção segura o de teste. Quem já viu dois amigos tentando voltar para casa depois de saírem de uma festa embriagados sabe como é isso. Nenhum dos dois vai chegar muito longe sozinho, mas quando estão juntos um pode contar com o outro se tropeçar.

Ajudando no burburinho

2006-06-06T19:01:00.000-07:00

Web 2.0 tá na moda, mais na moda do que aquelas músicas eletrônicas intercaladas com assobios. Por todo lado que eu olho tem alguém falando dela. Toda semana aparece mais uma aplicação hospedada em um domínio terminado em 'o.us'. Parece que todo mundo está usando bordas redondas e dá pra achar tags em todo site que entro. Outro dia desses minha mãe veio comentar comigo que a era da informação tinha acabado, que estávamos entrando agora na era da participação.

Tá bom, esta última não é verdade (a frase na verdade é de Jonathan Schwarts, agora CEO da Sun). Mas do jeito que as coisas andam, bem que podia ser. O fato é que Web 2.0 há muito tempo virou uma palavra de moda e seu sentido está cada vez mais obscuro. Para falar a verdade, todos os aspectos que citei no parágrafo anterior me lembram a tal segunda versão da web. Todos eles marcam de algum modo essa nova revolução.

Mas o que eu acho mais interessante é a frase de Schwartz. As pessoas deixaram de ser apenas consumidoras de informação para serem produtoras. O que estamos vendo não é uma revolução tecnológica, mas uma reviravolta cultural provocada pela evolução tecnológica. Nesse novo mundo as comunidades são as grandes responsáveis pela informação e comunidades são feitas de pessoas. Cada pessoa faz um trabalho pequeno, algo que tome tão pouco tempo que ela não se importa em cedê-lo. A grande mágica é a informação brotar da interação entre as pessoas. É assim que foi construída a Wikipedia, que hoje já é a maior enciclopédia do mundo.

Uma aplicação totalmente Web 2.0 que descobri há pouco tempo é o site last.fm. Ele é uma gigantesca base de dados sobre música construída quase que exclusivamente por seus usuários. Você se cadastra, instala um pequeno plugin no seu tocador de música e tudo que você escutar vai sendo enviado para o site. Seus dados são cruzados com os dos outros usuários e o sistema é capaz de sugerir algumas músicas com base nisso. Há também o aspecto Orkut da coisa. Depois que o sistema recebe uma certa quantidade de músicas suas, ele diz quem são seus 'vizinhos musicais', gente que tem gosto parecido com o seu.

Outra bem útil é o site digg.com que apesar de terminar em ponto-com, é uma das coisas mais Web 2.0 que se pode ter. As pessoas usam o site para indicar coisas interessantes que elas acharam (escavaram) na Internet e há um sistema de votação. As histórias mais populares vão borbulhando até a pagina principal e as menos populares ficam escondidas em alguma página obscura.

Curioso é que se olharmos por outro ângulo, vemos que toda essa revolução na verdade talvez seja uma volta às origens. Há alguns artigos, textos e páginas nessa grande rede que são verdadeiros fósseis cibernéticos. Vestígios de um tempo em que a rede era habitada por programadores, cientistas e outras criaturas mitológicas atualmente em extinção. Estes fósseis nos contam uma história de um lugar intocado pela bolha ponto-com dos anos 1990 onde ainda não havia grandes portais. Nesse lugar o conteúdo também era gerado por indivíduos e era interessante descobrir como as coisas se interligavam. As pessoas se comunicavam através de redes formadas por listas de discussão e grupos Usenet (você já ouviu falar nisso? Eles ainda existem!) e faziam páginas pessoais, uma espécie de ancestral dos blogs.

O que estamos observando hoje é somente a vontade de se comunicar, de fazer diferença e de ser parte de algo maior potencializada pelos avanços da tecnologia. O poder de informar (e desinformar) está sendo transferido dos grandes feiticeiros para o usuário comum.

Priorizar é com o cliente

2006-05-29T11:18:00.000-07:00

Eu queria saber desenhar como Raony. Ele ataca dessa vez com duas tiras de quadrinhos curtas mostrando a importância de envolver o cliente na priorização dos requisitos. É uma idéia de que já falei aqui ilustrada de forma inteligente e bem humorada.

Vale totalmente a visita.

Desmontando

2006-05-23T12:39:00.000-07:00

O termo fábrica de software foi cunhado há bastante tempo. Tempo o suficiente para que várias pessoas diferentes tenham lhe atribuído vários significados diferentes. Tempo o suficiente para chegar bem perto da inclusão no seleto grupo das palavras de moda, aqueles termos que de tanto serem usados indiscriminadamente acabam por perder o sentido.

Fábricas de software já foram linguagens e frameworks de alta produtividade. Fábricas de software já foram organizações para produção de linhas de produto. Mas fábricas de software não são linhas de montagem no sentido estrito da palavra.

Linhas de montagem servem para manufaturar produtos já projetados. Não se pode mudar de idéia uma vez que o produto tenha iniciado sua viagem dentro da linha de montagem. Incapacidade de adaptação a mudanças é exatamente o contrário do que precisamos para desenvolver software.

Um sistema de software é uma entidade tão abstrata quanto uma idéia ou uma teoria. Não se entende teorias sem vê-las em funcionamento. As pessoas normalmente não conseguem compreender as teorias sem observar alguns dos fenômenos que ela explica.

Pelo menos não a maioria das pessoas.

Precisamos que nossos processos de produção de software permitam que as pessoas vejam rapidamente pequenas partes do sistema funcionando de verdade. É por isso que precisamos que nossos processos de produção de software sejam altamente iterativos. É por isso que não podemos nos inspirar na linha de montagem. Ela só lida com construção e nós precisamos projetar algo. Afinal, software não é construído, é projetado.

Algum historiador poderia dizer que a indústria automobilística é a maior responsável pelo aperfeiçoamento das linhas de montagem. Não se deve confiar cegamente nos historiadores (aliás, não se deve confiar cegamente em ninguém — mas aqui devaneio demais: fecha parêntese). Mas há muito o que aprender com a indústria automobilística, qualquer que tenha sido seu papel na história das linhas de montagem.

As fábricas de automóveis projetam seus motores usando um processo bastante iterativo. Pelo menos é o que eu posso dizer daqui do lado de fora. Eu vejo que eles contratam pilotos e constróem pistas de prova exclusivamente para levar seus motores ao limite. Eu sei que eles organizam várias corridas para exibir sua tecnologia e compará-la com a dos concorrentes. Para fazer isso, eles precisam produzir e aperfeiçoar protótipos continuamente e eu poderia apostar como eles gostariam de produzir um protótipo funcional pelo menos a cada dia. O grande desafio para eles é que o retorno obtido com a construção de um motor completo nem sempre vale seu custo. Por isso eles precisam se contentar muitas vezes com cálculos matemáticos e simulações de computador.

Na indústria de software, estamos projetando um sistema que já é uma simulação de computador. Só precisamos tirar proveito disso.

Impressões do E-SOL/CEFET-PE

2006-05-08T16:22:00.000-07:00

Para quem está perdido, E-SOL/CEFET-PE significa Encontro de Software Livre do CEFET-PE. Mais detalhes no post anterior.

Agora que estamos esclarecidos, minhas impressões sobre o evento.

O evento foi um sucesso. O pessoal da organização do CEFET-PE e de todos os grupos locais que ajudaram fizeram um ótimo trabalho. Confesso que fiquei assustado quando fiquei sabendo que havia mais de 700 inscritos. Era minha primeira apresentação para público externo e por um momento cheguei a ficar preocupado de encarar a possibilidade de uma platéia lotada.

Mas no final deu tudo certo. Tive uma ótima impressão da comunidade de software livre de Pernambuco. A participação do pessoal, por exemplo, esteve em alta durante todo o evento. Na sexta-feira, só consegui ir à noite e tinha gente que estava lá desde a manhã. Na verdade, a maioria do pessoal tinha chegado cedo. O auditório estava bem cheio para as palestras sobre PHP e as experiências do SERPRO com software livre. Não tinha só aquela meia-dúzia de gatos pingados que seria de se esperar ao final do dia.

Novamente, parabéns para a organização e obrigado pelo espaço que me foi cedido.

Software Livre no CEFET-PE

2006-05-03T20:35:00.000-07:00

Eu deveria ter anunciado isso antes, mas minha memória infelizmente me traiu. Está um pouco tarde, mas vou anunciar mesmo assim. Neste próximo fim-de-semana, na sexta-feira e no sábado (dias 5 e 6), acontecerá o 1o Encontro de Software Livre do CEFET - PE.

Eu estarei lá nos dois dias e vou fazer uma pequena apresentação sobre a plataforma Eclipse, com a qual trabalho há um pouco mais de dois anos. Acho que já andei falando do EclipseFP aqui...

Estou realmente ansioso por este evento. O pessoal da organização tem feito um ótimo trabalho e tenho certeza que todo o esforço deles será coroado com um evento de sucesso.

Recomendado para qualquer um que esteja envolvido (ou esteja considerando se envolver) de alguma forma com software livre. É um evento não só para entusiastas, mas para todo e qualquer tipo de curioso.

A cascata iterada

2006-04-19T04:47:00.000-07:00

Hoje quero contar uma história. Uma pequena história de uma raça antiga: os programadores.

No início era o caos, programas nasciam do uso de alguma variação de programe-pra-ver-no-que-dá. Na verdade alguns programas ainda conseguem nascer desse jeito. Mesmo no século XXI, mesmo depois de todas as más experiências no decorrer do século passado.

Só que a coisa começou a dar certo. Algumas pessoas notaram que aquele negócio de programar computadores poderia realmente ser útil para a humanidade. Foi nessa hora que surgiram os estudiosos.

Eles começaram a desvendar as várias habilidades necessárias para produzir um programa de computador e chamaram essas habilidades de disciplinas ou áreas de conhecimento. A noção de disciplinas ou áreas de conhecimento já levou muita gente a dividir um projeto em fases correspondentes a elas. Esta mesma noção também deve ser a responsável por grande parte da especialização funcional observada em tantas organizações. É por estas e outras que muitos separam os cargos de analista e programador, por exemplo.

Depois de muito estudar, os tais estudiosos chegaram à conclusão que programar-pra-ver-no-que-dá era passado, coisa para neandertais e para os bárbaros não iluminados. Ninguém quer ser chamado de neandertal ou bárbaro, por isso as pessoas começaram a estudar quais eram as tais áreas do conhecimento e passaram naturalmente a organizar o tempo de modo que pudessem se concentrar em uma das habilidades de cada vez. Isso permitiria também ter pessoas especializadas em cada uma das áreas do conhecimento para fazer fábricas de software com linhas de montagem. Assim poderíamos dividir o trabalho entre operários especializados como se faz nas linhas de montagem de manufatura. Ao invés de apertar parafusos, os operários analistas poderiam somente analisar o problema (o que quer que isso queira dizer) e os operários programadores poderiam se concentrar em programar.

Com as novas descobertas, as pessoas passaram a organizar o tempo dos projetos em fases e caminhavam de fase em fase sem olhar para trás. Isso foi chamado de cascata, pela analogia com o que acontece com a água quando cai de cima de uma ribanceira: ela nunca tem a chance de voltar para onde veio, só seguir em frente.

O problema do desenvolvimento em cascata é que as pessoas tinham que confiar plenamente no trabalho que havia sido feito na fase anterior. Erros eram imperdoáveis. Erros pequenos em uma fase inicial se transformavam em erros monstruosos em fases posteriores. Além disso, não era possível modificar o destino do projeto uma vez iniciado. Você só tinha uma bala e era preciso acertar o tiro de primeira. E o alvo era difícil.

O pessoal estava notando como era difícil acertar o alvo, por isso entraram em cena os estudiosos novamente. Eles descobriram que o problema não estava na mira, mas na abordagem. Não era possível atingir o alvo, porque ele ficava se mexendo, mudando de posição toda hora. Era melhor reajustar a direção de tempos em tempos, e os estudiosos fizeram o que eles fazem quando precisam resolver um problema: inventaram um novo conceito. Eles desenharam espirais e todo tipo de formas malucas e chegaram a um nome para a novidade.

O nome era desenvolvimento iterativo, que queria basicamente dizer para fazer os programas em ciclos. Todas as habilidades deveriam ser utilizadas em todos os ciclos. A idéia é boa. Ao final de cada ciclo (e início do novo) a equipe poderia ver como as coisas estavam indo e reajustar a direção, se necessário.

Mas a idéia da cascata, da linha de montagem onde o uso de cada uma das habilidades precede o uso da próxima, parece que ainda estava muito enraizada na cabeça das pessoas a este ponto. Chegamos então à cascata iterada. As pessoas, ao invés de fazerem um grande projeto em cascata, faziam as coisas em ciclos que lembravam muito o modo antigo de trabalhar, mas em uma escala de tempo menor. Este novo jeito de trabalhar era melhor que o anterior. Bem melhor na verdade, pois permitia à equipe se adaptar um pouco melhor às mudanças.

O problema com esta nova abordagem é que enxerga as habilidades através de uma lente de correção muito forte e ainda as confunde com fases e especializações. Só que são somente habilidades e quando são tratadas como fases há desperdício, o mesmo desperdício que ocorria no desenvolvimento em cascata puro, só que em escala menor.

Aquelas disciplinas e áreas do conhecimento são somente habilidades, uma divisão didática que não precisa ser materializada em fases ou cargos. Como habilidades elas devem ser utilizadas a todo o tempo, por todos. Todo mundo deve estar projetando, planejando e testando o tempo todo, mesmo que pareça que estão simplesmente 'programando'.

Aliás, alguém ainda diz que é programador hoje em dia? Ou todo mundo prefere aqueles nomes pomposos?

Sempre alerta

2006-04-14T10:46:00.000-07:00

Esta semana consegui tirar tempo para fazer uma faxina na minha máquina de casa e finalmente consegui instalar o Ubuntu Dapper Drake. Esta versão ainda é experimental (deve ser lançada oficialmente em junho deste ano) e meu principal motivo para deixar meu Debian Stable de lado e me "arriscar" com ela tem um nome: XGL/Compiz.

Esses dois seres digitais já estão famosos depois de um vídeo que foi divulgado pela Novell há algum tempo. Eles transformaram minha área de trabalho plana em um fascinante desktop 3D com todo tipo de efeitos visuais. Fiquei tão boquiaberto que coloquei meus dois principais projetos para posar para a foto.

Este do lado esquerdo (e passando um pouco para o lado direito) é o Motiro, e o outro é o EclipseFP.

Eu já disse que o Ubuntu tem versões diárias? Isso mesmo: todo dia a uma certa hora é feito um build com todas as alterações feitas nas últimas 24 horas. Esse build é disponibilizado para o público e qualquer um pode baixá-lo e queimar seu CD em casa com tudo de mais quente que foi incorporado nos últimos tempos.

Imagine o trabalho que dá para fazer isso. É preciso que toda a equipe esteja muito bem sintonizada, que o processo de build seja extremamente padronizado e, principalmente, é preciso poder confiar no build. Apesar dessas versões diárias serem experimentais e todos que optam por usá-las serem exaustivamente avisados, é relativamente seguro usá-las. Você pode observar alguns comportamentos esquisitos (como os efeitos de transparência do meu XGL que parecem estar ausentes), mas nada crítico.

Esta prática de disponibilizar as mais quentes novidades para o público não é nova. Ela existe mais ou menos desde o início dos tempos e hoje é usada por vários projetos bastante conhecidos como Eclipse, Debian e Firefox (além do Ubuntu, claro). Se você puder fornecer a seu público builds fáceis de instalar em um bom ritmo, ele vai te retribuir com críticas, comentários e sugestões de melhoria no mesmo ritmo. Além disso, se você já estiver fazendo isso todo dia, pode poupar muita dor de cabeça na hora do release.

Estar sempre alerta não é bom só para os escoteiros.

Seu Nogueira

2006-04-06T06:25:00.000-07:00

Seu Nogueira é o barbeiro que me corta o cabelo há seis ou sete anos. Ele é um cara bastante detalhista e perfeccionista. Meu cabelo não é dos mais bonitos, mas ele consegue deixá-lo em um estado apresentável.

Seu Nogueira tem dias em que está – digamos assim – inspirado. Nestes dias ele pode passar vinte minutos realmente cortando seu cabelo e mais meia-hora fazendo alguns retoques e ajustes invisíveis. Se não houver mais ninguém na fila, a chance disso acontecer é perigosamente alta. Ele pode facilmente transformar um corte de cabelo de vinte minutos em uma obra de arte de uma hora.

Não que o resultado final não seja bom, mas quando isso acontece comigo eu fico nervoso com uma sensação de tempo perdido. Tenho certeza que ele não tem a mesma sensação, mas ela me aparece facilmente depois que acabo de ler a segunda revista. E olha que no salão dele não tem revista de fofoca e fotos de famosos, a maior parte são aqueles noticiários semanais que as pessoas lêem para ter conteúdo (há algumas revistas de quadrinhos bem interessantes também).

Saindo do salão de Seu Nogueira e chegando à minha área de trabalho onde programo computadores para ganhar o pão nosso de cada dia, noto que às vezes faço como o barbeiro. Às vezes acho algumas coisas tão interessantes que é difícil controlar a vontade de melhorar cada aspectozinho. Por que utilizar esta busca linear ineficiente se eu poderia usar um heap e ter o maior elemento do conjunto sempre disponível? Por que fazer uma lista com campos numéricos para ordenação se eu posso usar arrastar-e-soltar?

Porque quem está pagando é o cliente. Ele pode ter outras prioridades. Assim como eu prefiro sair mais cedo do salão com um cabelo menos perfeito, pode ser que aquela última novidade que me faz ficar em estado de semi-euforia não cause o mesmo efeito nele. Claro que posso (e na verdade, devo) esclarecê-lo das várias opções e seus custos. Mas quem tem que pesar os prós e os contras é ele. Quem vai ganhar (ou perder) com as escolhas é ele, e não eu. Meu trabalho é ajudá-lo a encontrar a melhor forma de maximizar seus ganhos (e evitar perdas) agradando os clientes dele.

O personagem dessa história é baseado em fatos reais, mas o nome é fictício para proteger sua inocência.

Em busca de um certo fator X

2006-03-27T04:48:00.000-08:00

Há basicamente dois tipos de organizações que procuram uma certificação de qualidade de processo: aquelas que querem mudar seus processos (de preferência para melhor) como efeito colateral e aquelas que não querem mudar nada, mas querem a certificação como diferencial competitivo.

O interessante é que certificações de processo só dizem respeito a – adivinhem só – processos. As organizações que emitem os certificados não se comprometem com a qualidade do produto. Um certificado desses quer dizer somente que alguém é organizado. O problema é que você pode saber que alguém é altamente organizado e nunca conseguir arrancar um bom produto dele. Ele pode te vender os piores pesadelos que sua imaginação possa conceber, mas vai fazer isso de modo completamente controlado.

Sério, é verdade. O grande trunfo das certificações de processo é que acreditamos que um processo de qualidade produz resultados de qualidade. Não há nada de estranho nisso. Em alguns casos isso realmente acontece.

Em outros não.

O diferencial competitivo verdadeiro, a qualidade de produto, não é alcançado por certificações. Talvez elas não cheguem nem perto disso. A melhor forma de avaliar a qualidade de um produto ou serviço é perguntar a seus clientes. Para eles o processo é um pequeno detalhe, um fator mínimo. Talvez isso seja decepcionante para quem está à procura do processo ou metodologia perfeita, mas é verdade.

Ao invés disso, o verdadeiro fator de sucesso pode estar em locais quase inexplorados, como um tesouro escondido no lugar mais óbvio. Um desses fatores por muitas vezes ignorado é a equipe. Bons profissionais bem motivados podem operar milagres. Uma equipe de profissionais bons e motivados sem nenhum processo formal é capaz de fazer produtos de alta qualidade. Isto pode não acontecer com muita freqüência, mas é possível. Porém é muito mais raro uma equipe de profissionais ruins ou desmotivados com um ótimo processo fazer algo de qualidade. Ainda não foi inventado nenhum processo capaz de conduzir esta última espécie ao sucesso. E se eu tivesse que apostar, diria que nunca vai ser.

Cada vez mais me convenço que estes são dois ingredientes essenciais dentro do caldeirão que produz o sucesso. A má notícia é que nenhum dos dois é fácil de se conseguir.

Bons profissionais são artigos raros e valiosos, tão disputados quanto um copo de água no deserto e criar motivação é um desafio por si só. Motivar bons profissionais é uma tarefa apenas para os mais insanamente destemidos.

Estes times de elite não vão trabalhar só por dinheiro. Claro que é preciso remunerá-los bem, mas esta é a menor parte da questão. Bons profissionais vão querer superar desafios, tomar decisões estratégicas e resolver problemas interessantes. Eles não vão ser seduzidos por escritórios luxuosos nem por algumas palavras da moda espalhadas a esmo em propostas de emprego.

Pelo menos não os verdadeiramente bons.

(re)Construindo

2006-03-24T12:19:00.000-08:00

Você começaria a construir um prédio sem antes ter uma especificação detalhada?

Eu com certeza não me arriscaria. Mas tenho mais uma pergunta: se você pudesse construir um prédio e reconstruir partes dele livremente a custo quase zero, você esperaria uma especificação detalhada para começar a construir?

Eu também não.

Desenvolver software é muito mais parecido com a segunda do que com a primeira situação e é por isso que esta metáfora de construção não pode ser levada muito longe. Ao contrário dos produtos da construção civil, é fácil e barato mudar uma parte ou outra de um sistema mesmo que ele já esteja em produção, é fácil até trocar a ordem dos andares. Claro que é mais barato fazê-lo em fase de desenvolvimento, mas a diferença de custo pode ser controlada e mantida a níveis razoáveis. A principal razão deste baixo custo não é nenhum segredo: software não é construído por pessoas.

Ao invés disso, as pessoas apenas especificam software utilizando coisas chamadas de linguagens de programação. A parte da construção propriamente dita -- a montagem a partir de uma especificação -- é feita automaticamente por ferramentas como compiladores e interpretadores. No mundo do software, os construtores são coisas como estas e o tempo de trabalho deles é muito mais barato que o dos construtores humanos. Na verdade, pode-se encontrar alguns excelentes a custo zero.

É como se houvesse máquinas distribuídas gratuitamente que fossem capazes de receber um conjunto de plantas e construir rapidamente um prédio ou uma ponte sem nenhuma intervenção humana. Infelizmente, os engenheiros civis não têm essa sorte. Mas seria estupidez se os engenheiros de software não se aproveitassem dela para fazer seus produtos e colocá-los rapidamente à disposição dos clientes.

Ainda bem que eles fazem isso.

Bom, pelo menos alguns fazem.

Pagando as dívidas

2006-03-16T03:42:00.000-08:00

Estou lendo O valor do amanhã de Eduardo Giannetti. Ele é um economista (não um programador, como a maioria dos autores que leio) e este livro em particular é sobre trocas e negociações intertemporais. Quando escuto dizer que um economista está falando de trocas intertemporais, não consigo evitar pensar em juros aplicados ao mercado financeiro. O que achei interessante é que Giannetti vê os juros em um contexto maior, identificando-os, por exemplo, na biologia. Aparentemente isto não tem nada a ver com software ou tecnologia, mas é por isso que o subtítulo do blog fala em devaneios.

Acontece que existe no cérebro dos programadores um mecanismo que faz ele relacionar (quase) qualquer coisa que lê com seu trabalho. Talvez os mais antenados já tenham identificado aonde quero chegar: o conceito de dívida de projeto, que talvez você já conheça pelo termo em inglês design debt.

Giannetti destaca a diferença entre envelhecimento e a senescência, dois mecanismos geralmente referenciados apenas pelo primeiro termo. Envelhecimento é o simples passar do tempo, o mecanismo pelo qual avançamos em idade e experiência. Senescência é o mecanismo que debilita um organismo com o passar do tempo. A senescência é o custo pago pelo vigor da juventude. Assim como os juros financeiros, a senescência é um custo pago na velhice (futuro) em troca de um benefício na juventude (presente). O organismo dispõe de tanta energia na juventude justamente porque vai pagar por ela na velhice.

O universo do desenvolvimento de software não está livre dos juros. Para cada atalho que tomamos no presente, cada "jeitinho" que damos, serão cobrados juros no futuro. Assim como no mercado financeiro, a quantidade de juros envolvidos na transação depende do tamanho do empréstimo que tomamos. Assim como não se deve rolar muito as dívidas financeiras, não se deve postergar demais o pagamento das dívidas de projeto. Quanto mais tempo correr, mais juros terão que ser pagos. Isso é um bom negócio para quem empresta dinheiro, mas não para quem produz software.

Todos nós queremos sistemas que durem bastante tempo e que continuem gerando dividendos: sistemas velhos. Mas ninguém quer um sistema senil, um no qual a receita não compense o esforço gasto com o pagamento de juros. Então é melhor consertar hoje aquelas pequenas gambiarras que você fez ontem. Cada vez que pensar "puxa, isso deveria mesmo ser feito de outro jeito, mas vou fazer desse jeito aqui para ir mais rápido", não pare na parte do pensamento. Uma abordagem muito mais indicada é fazer do jeito rápido, ter testes que comprovem o funcionamento e consertar para o jeito certo.

Nota: O Motiro foi oficialmente lançado nesta segunda-feira. Pensei em fazer um post para anunciar isso, mas este blog já está tão infectado com notícias sobre Motiro que preferi fazer somente esta notinha aqui. Maiores informações (e links para o código-fonte e downloads) no blog do projeto.

Projeto ganha nome

2006-02-06T03:55:00.000-08:00

E o nome é Motiro.

Motiro é uma palavra tupi-guarani que, no português moderno, deu origem a mutirão. Os linguistas de plantão podem corrigir, pois a grafia original é motirõ. Nós apenas decidimos remover o til para dar uma sonoridade diferente.

Mutirão é uma reunião para trabalho em um objetivo de interesse de todos os participantes. Exemplos bastante comuns são as colheitas e construção de moradias. Num mutirão as pessoas se ajudam mutuamente a fim de dividir o resultado final do trabalho. Todos trabalham para todos os outros e para si mesmos. Não há mecanismos de centralização de poder, ninguém é imposto como chefe. Ao invés disso há lideres, e eles emergem naturalmente durante a atividade.

Um mutirão é uma organização dinâmica e descentralizada. Nele a responsabilidade é dividida ao máximo entre todos os participantes. Cada participante escolhe uma pequena parte do trabalho, extremamente fácil de ser gerenciada, de acordo com o que julga ser melhor para a comunidade como um todo.

Esta descentralização da capacidade de decisão é um dos pilares da filosofia Just-in-time que, aliás, funciona bem para construção de motores a jato e pode funcionar também para projeto de software, como mostram Mary e Tom Poppendieck em seu Lean Software Development: An Agile Toolkit.

Quem estiver interessado pode contactar a Equipe Motiro através de um grupo de discussão hospedado no Google Groups ou visitar a página do projeto (que está em construção) no BerliOS Developer.

Atualização em 30 de março de 2006: reelaborei alguns trechos sobre Lean e Just-in-Time depois de discutir o assunto com Carlos Miranda. Estou mais confortável com o novo texto. Obrigado, Carlos.

Pequeno manual para remoção de rochas magmáticas

2006-02-01T08:00:00.000-08:00

Tenho uma confissão a fazer. Hoje eu apaguei umas 20 linhas do código de um sistema.

Afinal quem seria desumano a ponto de apagar um trecho de código em que investiu tempo e esforço para escrever? Quem em sã consciência cogitaria esta possibilidade?

Mas eu tive minhas razões. O trecho que eu apaguei é o que eu chamaria de solidificação mineral de código indevida. Sabe aqueles trechos de código que estão ali mas você não sabe para que diabos escreveu aquilo? Você passa um bom tempo imaginando qual a utilidade daquilo e não consegue se lembrar nem elaborar uma hipótese plausível. O trecho de código é quase um apêndice do seu sistema. Está lá. Funciona. Mas ninguém usa para nada.

Este anti-padrão foi identificado por William Brown, Raphael Malveau, Hays "Skip" McCormick e Thomas Mowbray no livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis e observado por milhares de programadores em uma quantidade astronômica de projetos. Os autores do AntiPatterns chamam isso, sugestivamente, de bloco de lava. O nome é uma alusão à erupção de um vulcão. Depois que passa a fúria da lava, ficam alguns blocos solidificados que não servem para muita coisa.

O código que eu apaguei hoje não era exercitado por nenhum teste do projeto (não estou usando nenhuma ferramenta para monitorar a cobertura de código, mas executei os testes após a exclusão do código e tudo continuou tão verde quanto antes). Além disso, eu não consegui pensar em nenhuma utilidade para aquele código mesmo tentando bastante. Então eu respirei fundo, apaguei o código e enviei a modificação para o repositório central. Até agora ninguém reclamou. E se reclamar vou pedir que escreva um teste que demonstre a utilidade do código. Isso vai impedir que o próximo programador desavisado apague tudo novamente.

Cada linha de código de um sistema em evolução (o que engloba a maior parte deles) aumenta o custo de manutenção. É mais uma linha que vai precisar ser lida, compreendida e testada. É como se o projeto fosse uma mala e as linhas de código as peças de roupa. Cada peça de roupa colocada na mala é um peso a mais que precisa ser carregado. Uma camisa ou um par de meias sozinhos não pesam muito, é quando eles se juntam que a mala fica pesada. Ao apagar o código, eu optei por carregar menos bagagem.

Talvez eu não esteja tão louco quanto pensei.

EclipseFP 0.9.1 disponível

2006-01-27T11:51:00.000-08:00

Hoje foi publicado o release 0.9.1 do projeto EclipseFP. Estou trabalhando neste projeto desde outubro do ano passado e este é o primeiro release de que participo.

O EclipseFP é uma IDE para a linguagem Haskell baseada na plataforma Eclipse. A intenção é ter algo como um HDT (uma a sigla para Haskell Development Tooling), parecido com o JDT (a IDE de Java do Eclipse), com suporte a coisas como assistente de código, refactoring e debugging.

Neste release a maior parte do meu trabalho foi centrada em construir um parser para Haskell em Java. O parser antigo era escrito em Haskell e acessado pelo código Java através de JNI. Uma desvantagem grande dele é que só havia uma versão para plataformas win32, o que quer dizer que os usuários de outras plataformas como Linux e Mac OSX não tinham acesso a nada que envolvia o parser. Agora eles têm.

Para o próximo release estou pensando em trabalhar no suporte ao compilador e no modelo da linguagem, indispensável para termos coisas como 'Abrir declaração' (tecla F3 no Eclipse/JDT).

Novo projeto

2006-01-20T03:37:00.000-08:00

Acredito bastante na eficácia de equipes auto-gerenciadas, formadas por programadores qualificados e motivados. Em contraposição à equipe com um gerente razoavelmente motivado e programadores subordinados a ele não tão motivados assim, o que em muitos casos os torna desqualificados.

Para estas equipes auto-gerenciadas atingirem seu potencial máximo, elas precisam do mesmo material que o gerente centralizado precisa: informação. Obviamente, a informação precisa ser democraticamente distribuída. Todo programador (provavemente também todo usuário) é um agente para a melhoria, por isso todos precisam ter acesso fácil à informação.

Por isso, estou iniciando um novo projeto. A idéia é fazer um portal para projetos de desenvolvimento de software, um local onde a comunidade possa se reunir e rapidamente obter informações sobre o bem-estar geral do produto. Em poucas palavras: reunir em um só local a multitude de informação encontradas em um projeto típico. Coisas como contribuições em código ao repositório de controle de versão, alterações na wiki, situação do build e mensagens nas listas de discussão. Deste caldeirão de informação, deste caos aparente, podem surgir idéias maravilhosas. Só é preciso deixar tudo ferver e esperar acontecer.

Este projeto vai ser desenvolvido em código-aberto, em algum site do tipo Source Forge ou BerliOS. Mais notícias em breve.

Torne testável o que não puder testar

2005-12-26T09:57:00.000-08:00

A frase acima foi inspirada em uma de Galileu Galilei: "Torne mensurável o que não puder medir". Na Itália do século XVII, ele estava falando da necessidade de medidas precisas para o saber científico. O bom cientista deve sempre conseguir um meio de quantificar o que estava estudando, mesmo que a medida não seja ainda padronizada. A partir disto ele pode comparar resultados, tem mais embasamento para suas hipóteses e pode se comunicar melhor com seus pares. A medição é indispensável para um bom estudo científico. Do mesmo modo, os testes são indispensáveis para uma boa peça de software. Código testável permite que testes sejam escritos facilmente, sem necessidade de grandes trechos de código de configuração de ambiente. Para alcançar isso é necessária uma boa dose de modularização e desacoplamento, que são sem dúvida boas coisas. Uma ótima prática para escrever código testável é escrever os testes antes do código de produção. Com isso, o código de teste tende a ficar pequeno, o que significa que o código de produção tem uma interface enxuta e bem definida (o que, não preciso dizer, também é uma boa coisa). Os testes deixam de tentar se adaptar ao código e o código é que passa a se adaptar aos testes. De um certo modo, o código é modelado pelos testes.

Metáforas e analogias em software

2005-10-17T11:15:00.000-07:00

Acho que se fizermos uma pesquisa sobre que práticas de XP são mais utilizadas ou fáceis a metáfora tem grandes chances de ficar segurando a lanterna. 8 em cada 10 pessoas (aviso logo que estou chutando) acham que sua aplicação é questionável. Porém, a grande surpresa é que elas estão sim utilizando metáforas o tempo todo para desenvolver software.

A informática é um campo construído sobre o abstrato e virtual. Metáforas são um excelente mecanismo para entender estas peças abstratas e muitas delas têm sido historicamente usadas com sucesso. Hoje em dia falamos naturalmente de 'área de trabalho', 'fluxo de dados', 'rede', 'pool de recursos', 'pipes (canos)', 'crawlers' ou outros termos.

Na minha opinião a grande dificuldade de se usar a metáfora é saber elaborar uma que seja útil e duradoura. Isto dificulta, mas não impede, seu papel como ferramenta de comunicação. Além disso, muitas das metáforas que usamos acabam nascendo naturalmente durante o processo. Seja em uma conversa informal entre pares ou durante a escrita de um pedaço de código.

Outro perigo eminente é o risco da metáfora ser sobre-utilizada, ou seja, forçada para além de onde ela é aplicável. Em alguns casos isso é detectável, pois a coisa começa a ficar um pouco ridícula, em outros casos a fronteira pode não ficar clara e levar a decisões incertas. Há pouco tempo hove uma discussão na lista de XP sobre metáfora, destaco uma mensagem de Tim Haughton em que ele relata uma metáfora bem sucedida que foi sobre-utilizada por alguns.

Como tudo em XP, a utilização da metáfora é algo pequeno e pontual que influencia no todo e, talvez por isso, fica invisível a muitos olhos. Eu como xispista acredito que o todo é maior que a simples soma das partes. É assustadora a diferença que as interações entres as partes podem fazer nesta equação.

Adote XP do jeito XP

2005-10-14T05:11:00.000-07:00

Há algum tempo -- não sei bem certo quanto, mas o suficiente para que eu possa dizer 'há algum tempo' -- venho acompanhando a evolução de XP como processo de desenvolvimento. Muitas vezes as práticas são um pouco polêmicas, precisando de um pequeno trabalho de convencimento para vencer a inércia inicial. Uma parte das pessoas acha que é tudo uma bagunça só, que coisas assim tão simples não podem dar certo. Outra parte está à procura de alternativas a processos um tanto quanto cerimoniosos. Estas últimas pessoas estão inclinadas a mudar, mas talvez não queiram arriscar tudo jogando o antigo processo fora e começando a usar um 'processo novo que estão usando por aí' do zero.

Para ambas as partes, meu conselho é

Adote XP do jeito XP.

Se você quiser apenas testar uma abordagem metodológica nova, se já se decidiu por mudar o processo antigo ou se não possuía nenhum processo e quer adotar algum, o jeito XP é fazer tudo incrementalmente. Começar com partes pequenas e adicionar outras parte também pequenas gradativamente, deixando que a interação entre elas gere um todo maior que a soma das partes. E fazer isto tudo 'na vera' e sempre pensando por que uma coisa ou outra não está dando resultados em pouco tempo.

Sim, pouco tempo. As práticas de XP foram especialmente projetadas para que apresentassem resultados após pouco tempo de adoção e, além disso, um fator decisivo para a adoção é que elas são recompensantes também em termos psicológicos. Você simplesmente se sente bem de ver a 'luzinha' verde que indica os testes passando, de saber que poderá refatorar o que não estiver agradável, de poder trabalhar lado a lado com todos os seus pares e de todos eles conhecerem tanto do sistema quanto você.

Dan Bunea publicou uma mensagem na lista de XP que esclarece um pouco essas dúvidas. É interessante ler também o restante das mensagens relacionadas, a discussão por lá está bastante produtiva. Meu resumo da idéia dele é: convença a você mesmo, convença a seus pares, convença a gerência e, finalmente, convença o cliente. E faça tudo isso praticando, colhendo os frutos eXtremamente ráPido.

Você já começou a acolher a mudança?

Refactoring

2005-09-24T20:15:00.000-07:00

Dia desses, eu estava perdido na web, lendo sobre refactoring. Para quem está envolvido com desenvolvimento ágil, o vocábulo já paz parte do jargão diário e quem pratica XP provavelmente não consegue imaginar como existe gente que não usa a técnica deliberadamente.

O novato desavisado tende a reduzir tudo que escuta ao que lhe parece a essência da coisa, para simplificar e tentar entender o assunto. Falar em 'melhorar a estrutura do código sem modificar seu comportamento externo' pode parecer a este novato uma mera desculpa para ficar mimando o código, dando mais atenção a ele do que o estritamente necessário. Refatorar está, aparentemente, ligado a 'consertar o que não está quebrado'.

Aparentemente.

Na verdade, não tem nada a ver com isso. Refactoring é um dos processos que nos permite evitar ter todas as idéias sobre a arquitetura do sistema no início do desenvolvimento. Refactoring permite modificar o design do software segura e rapidamente quando necessário (e somente quando necessário). Com refactoring, podemos nos permitir aprender sobre o sistema ao mesmo tempo que o desenvolvemos. Não precisamos nos limitar a soluções pré-fabricadas (mas podemos fazer uso delas), muito menos projetar todo o sistema antes de começar a codificar.

Vantagens demais para ser verdade? Acho que não. Na verdade já fazemos isto todos os dias. Fazemos isto, por exemplo, quando identificamos uma lógica de execução comum para duas rotinas e dela extraímos uma terceira. Ou então quando movemos responsabilidades de uma classe para outra, como mostra Martin Fowler neste exemplo do seu 'Refactoring: Improving the design of existing code' (que já possui tradução para nosso querido idioma pátrio).

Digamos que foi feito um sistema para uma locadora de filmes (sim, Martin Fowler também tem seus momentos de baixa criatividade). Este sistema foi feito por uma equipe ainda não iniciada às artes do refactoring e que também não entendia muito de herança e polimorfismo na época. O cálculo de débito do cliente é calculado na classe Customer com auxílio do seguinte método privado, responsável pelo cálculo de débito proveniente de uma única locação.

class Customer {
  ...
  private double amountFor(Rental aRental) {
    double result = 0;
    switch (aRental.getMovie().getPriceCode()) {
      case Movie.REGULAR:
        result += 2;
        if (aRental.getDaysRented() > 2)
          result +=
            (aRental.getDaysRented() - 2) * 1.5;
          break;
      case Movie.NEW_RELEASE:
        result += aRental.getDaysRented() * 3;
        break;
      case Movie.CHILDRENS:
        result += 1.5;
        if (aRental.getDaysRented() > 3)
          result +=
            (aRental.getDaysRented() - 3) * 1.5;
        break;
    }
    return result;
  }      
  ...
}

Este método é utilizado por outro maior que calcula todo o débito do cliente. A equipe que desenvolveu o sistema original teve ao menos o cuidado de extrair este método para evitar que o maior ficasse exageradamente grande, mas não notaram que o novo método na verdade não pertence à classe Customer. Note que o método só mexe com atributos da classe Rental e pertence logicamente a ela. Podemos mover o método para ela e chamar apenas rental.getCharge() no local original sem perder o significado.

Depois disso, é hora de transformar esse switch altamente suscetível a erros em uma chamada de método da classe Movie, talvez utilizando o padrão State. Refactoring é a simples aplicação de modificações pequenas como estas de modo controlado. Acho que já deu pra pegar a idéia.

Talvez tenha alguém dizendo: "Mas isso não pode dar certo! As mudanças são pequenas demais para serem signiticativas."

Sim, as mudanças são pequenas. A força delas não vem da utilização isolada, mas contínua. Aqui o todo é maior do que a soma das partes, por causa da interação entre as várias mudanças.

Mas não nos limitemos a alguns exemplos. Fazer isso seria agir como o novato do qual falamos. Começar a aplicar refactoring na prática é tão fácil quanto não se limitar a duplicar um trecho de código deliberadamente, mas capturar a duplicação e escrever o caso geral. Isto pode se concretizar na extração de uma rotina, na identificação da oportunidade de usar um design pattern ou de muitos outros modos que vamos descobrindo quando tentamos.

Desenvolvimento ágil e punk rock

2005-09-03T11:08:00.000-07:00

Quem me conhece sabe que gosto um pouco de música e outro pouco de desenvolvimento de software. Por isso eu gosto de usar a música para entender o que acontece nesse mundo complicado cheio de aplicações, frameworks, sistemas e metodologias que é o mundo do software.

Quando os Ramones inventaram o punk rock lá pela década de 70, eles quiseram simplificar o rock 'n roll, aproveitando a experiência adquirida pela comunidade em 20 anos de história. Eles se perguntaram: 'Qual é a essência do rock por trás desses solos infindáveis e arranjos complicados?' e a resposta foi o trio baixo, guitarra e bateria e canções simples e curtas.

O que os autores do manifesto ágil e centenas de programadores (eu me arriscaria a dizer milhares) em todo o mundo fizeram foi bem parecido. Eles se perguntaram 'Qual é a essência do desenvolvimento de software por trás dessas inúmeras ferramentas e processos complicados?' e despiram a prática comum em busca das necessidades fundamentais. O interessante é que a maioria dessas necessidades podem ser supridas por práticas simples, desde que saibamos como e porquê utilizá-las.

O ser humano tem uma certa tendência a se acomodar. Quando estamos acostumados com alguma forma de trabalho, tendemos a acreditar que ela é 'A' solução. Até mesmo quando ainda não tivemos tempo de nos acostumar a nenhuma forma de trabalho, tendemos a aceitar a forma que parece a princípio mais 'séria'. E, para o explorador incauto, a 'seriedade' aqui quase sempre é sinônimo de formalidade.

Algumas pessoas acreditam que o punk rock talvez tenha ido longe demais na simplificação. Uma parte dessas pessoas estava acostumada demais com o 'rock antigo' para serem capazes de avaliar imparcialmente o novo movimento. A outra parte simplesmente não entendia a razão daquilo e preferia confiar no que parecia mais 'elaborado'.

Se você é um dos que acha que o desenvolvimento ágil é simples demais para funcionar, mas está intrigado por ouvir tanto falar nisso, os links nesse post são um bom ponto de partida. Boa sorte.