A cascata iterada

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

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

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.