Mergulhando no Caos

Aqui vai um pequeno resumo de como adiciono recursos aos meus sistemas:

1. Eu identifico (ou alguém me chama a atenção para) alguma necessidade
2. Escrevo alguns testes para a necessidade
3. Escrevo o código para fazer os testes passarem
4. Depois que os testes estão devidamente esverdeados, reestruturo o código para que fique um pouco mais elegante
5. Repito até que a necessidade esteja satisfeita

Este é o modo TDD de fazer as coisas e pode parecer estranho para quem não está acostumado. Mas o que não é estranho para quem não está acostumado?

Por conseqüência este modo esquisito também é o modo XP. Pelo menos para quem segue a cartilha. E, olhando por este lado, parece que XP inverte bastante as coisas. Você faz os testes antes de fazer o código e (re)define a estrutura depois de ter o código pronto. É como programação para caranguejos: você anda e consegue chegar aonde precisa, mas o modo como isso é feito não é muito parecido com o que se vê normalmente. A não ser, é claro, que você esteja vivendo entre caranguejos.

O que eu inicialmente aprendi na escola foi que deveria pensar um pouco em como estruturar a aplicação antes de começar a escrever código. Para registrar (ou documentar, para usar uma palavra um pouco mais corporativa) a estrutura, poderiam ser elaborados diagramas usando uma linguagem gráfica padrão. Depois era hora de implementar o design. Implementar, em corporativês, é escrever o código correspondente ao design (que é a palavra usada para indicar a estrutura pré-projetada). Finalmente, depois que o código estivesse escrito, chegava a hora de testar a coisa.

Em algum ponto do tempo, devo ter esquecido isso tudo. Pelo que eu descrevi, parece que estou fazendo tudo ao contrário, andando de costas. Afinal, eu começo pelos testes e só no final do ciclo me preocupo com a estrutura. Mas a verdade é que continuo fazendo tudo na mesma ordem. Os testes que faço no início servem para que eu pense um pouco e defina uma estrutura mínima para o código que estou prestes a escrever. Eles definem como o novo pedaço de código vai se ligar ao resto da aplicação, assim como fazem os diagramas. Só que têm uma vantagem bem importante: depois que eu quiser validar tudo, os testes já estão prontos. Do mesmo modo, a atividade final de reestruturação é uma preocupação principalmente com a estrutura da aplicação e, como isso tudo é um ciclo, estar no final é o mesmo que estar no início.

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.

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.

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.

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.

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.

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.

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?

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 é 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.