Mergulhando no Caos

Twitter é um serviço para publicação de mensagens curtas. As pessoas usam todo tipo de aparelho eletrônico para responder a famigerada pergunta “O que você está fazendo?”. As mensagens precisam caber em 140 caracteres. Isso, além de possibilitar mensagens rápidas enviadas de aparelhos celulares, faz com que todo mundo se concentre em dar o recado com poucas palavras.

Quando tomei conhecimento do Twitter, minha reação inicial foi questionar porque diabos alguém iria querer saber o que eu estou fazendo. Eu definitivamente não estou nem aí para o que milhares de anônimos com acesso à Internet estão fazendo agora. Afinal de contas, esse é mais ou menos o mesmo propósito de um blog-diário, só que mais instantâneo.

Mas eu estou muito interessado em aprender com eles. Não importa quem sejam, se eles podem falar algo sobre um assunto que me interesse, quero pelo menos tentar escutar.

Eu tenho o hábito de compartilhar pensamentos rápidos com as pessoas através de mensagens curtas. Todo mundo que está na minha lista de contatos em alguma rede de mensagens instantâneas já deve ter recebido uma dessas (geralmente acompanhadas de um link). Este meio é muito bom para compartilhar estes estalos, momentos eureka e pequenas descobertas. Porém estas mensagens simplesmente querem ser públicas e não gostam de ficar confinadas entre duas pessoas apenas. Uma das maiores evidências que tenho disso é o fato das minhas mensagens nunca serem enviadas para uma pessoa só. Ao invés disso, quase todo mundo que está on-line no momento recebe uma cópia. Além disso, muitas vezes também tenho vontade de publicar as mensagens neste blog aqui, só não acho que seja a mídia mais apropriada.

Assim como aconteceu com os blogs, eu deixei minha impressão inicial de lado e descobri que um serviço de mensagens públicas não precisa ser usado para futilidades e pode ser muito útil para compartilhar estes pensamentos breves. Faz muito sentido tornar público aquilo que não se tem certeza a exatamente quem pode interessar. Assim as pessoas podem escolher por si mesmas o que ler. Por cima disso tudo, como uma cobertura especial, está o robô de mensagens instantâneas que me permite manter a mesma forma de publicação que usava antes. Ou seja, eu não preciso entrar em algum site especial para publicar minhas mensagens, posso usar meu serviço de mensagens instantâneas favorito como sempre fiz. Só que agora ao invés de mandar uma mensagem para uma ou duas pessoas que eu escolher, posso “falar” apenas com o robô e as pessoas podem escolher me dar um segundo da sua atenção ou não.

Portanto, quem quiser acompanhar alguns devaneios mais curtos do que normalmente encontra aqui neste blog, é só seguir para http://twitter.com/thiagoarrais e quem recebia minhas mensagens de vez em quando só vai ser importunado se quiser. Lá ninguém vai encontrar muita coisa sobre o que eu estou fazendo agora, mas pode ter uma idéia do que estou pensando.

P.S.: Não consegui achar um artigo na wikipedia em português sobre a palavra “Eureka”. Será que alguém tomaria o tempo para começar um?

Analogias costumam ser usadas para tentar entender melhor algo. A idéia é bastante simples: compara-se o objeto ou conceito que não se conhece a outro bem conhecido com o objetivo de aprender alguma coisa ou formar algum argumento. Muito já se descobriu com ajuda das analogias, mas elas também podem ser bem perigosas. Eu poderia repetir tudo aqui, mas o Marcos Pereira saiu na minha frente com o primeiro artigo do seu novo blog que discute várias das mais furadas analogias para desenvolvimento de software (e uma das certeiras). Ao invés disso, este artigo vai se deter em apenas uma delas: a das fábricas.

Fábricas são instalações onde as pessoas se reúnem para produzir um certo tipo de artigo. Fábricas de sapatos fazem sapatos, fábricas de postes fazem postes e fábricas de software fazem software.

Simples assim.

Mas nem tanto…

Fábricas são instalações com estrutura e procedimentos de produção pautados por um certo modelo. Afinal de contas, não são só as fábricas que se encaixam na definição acima. Organizações como oficinas e ateliês também podem perfeitamente produzir artigos de qualidade. A diferença está na organização interna.

Um dos maiores problemas das analogias é que costumam ter limites não muito bem definidos. Toda analogia tem um ponto de quebra a partir do qual não faz mais sentido e nem sempre é fácil identificar até onde podem ser aplicadas. Nas mais rasas este ponto de quebra é alcançado bem rapidamente como neste caso das fábricas.

Ao pensar em fábricas é comum lembrar de linhas de montagem, funcionários altamente especializados e produção em massa. Tudo isso faz muito sentido em boa parte das fábricas, como as de sapatos, automóveis e componentes eletrônicos, mas não tem grande valor para quem produz software.

Software não se encaixa num modelo de produção em massa e manufatura porque não é repetição. Fazer software é projetar, não construir. Ninguém pensa em fazer o mesmo projeto do mesmo sistema duas vezes, mas muita gente pensa em licenciar para dois clientes diferentes. Fábricas são excelentes para reproduzir produtos idênticos ou com pouca variação, mas projetar software — assim como projetar carros, telefones e praticamente qualquer coisa que se possa imaginar — é um processo criativo que não se adapta muito bem à manufatura. Fábricas são bastante eficientes para reproduzir produtos em larga escala. Só que ninguém precisa de uma fábrica para reproduzir software, uma máquina de prensar discos já basta (sim, desenvolvedores web, ainda existe gente que precisa distribuir software em discos).

Muitos programadores felizmente já notaram que especialização extrema e processos de desenvolvimento repletos de fases — e, conseqüentemente, entregas parciais — não fazem muito sentido. Estas abordagens servem muito bem para reproduzir produtos. Só que software não é feito de madeira e cola, nem de aço e solda. Mas de idéias e bytes. Por causa de sua natureza imaterial, reproduzir software é muito simples e barato. Portanto, o problema da reprodução já está resolvido, o que queremos é projetar software com qualidade e de forma economicamente eficaz. Este é o fator primordial que impede esta analogia de ir tão longe.

Muita gente sabe disso, mas misteriosamente ainda gosta de chamar suas organizações de fábricas. Ao contrário do que possa parecer, alguns desses não são completos idiotas e sabem pelo menos alguma coisa do que estão falando. Quando falam em fábricas, eles não estão pensando em programadores operários apertando parafusos, mas em coisas interessantes como linguagens para certos domínios de conhecimento e frameworks especializados. Apesar disso, essas pessoas fazem esforços tremendos para extrapolar a metáfora e chegam a chamar linguagens de fábricas (é verdade, essa eu vi em uma lista de discussão que, infelizmente, não tem arquivos públicos e não pode ser referenciada aqui). Várias dessas idéias fazem todo o sentido do mundo, mas definitivamente não são fábricas.

Provavelmente muitos dos pesquisadores modernos fazem a analogia por razões históricas e não de forma intencional. O problema é que, devido a sua natureza metafórica, a expressão pode ser mal interpretada e, infelizmente, isso não acontece tão raramente quanto gostaríamos. Tem gente que gosta de fingir que acompanha as novidades do meio acadêmico e já viu a expressão “fábrica de software” repetida várias vezes em títulos de artigos científicos. Mas o título deve ser a única linha que eles lêem. Depois de olhar para o nome, acham que podem organizar suas “fábricas” exatamente como manufaturas juntando programadores aos montes para repetir código e fazer trabalho mecânico em geral. Afinal, parece ser a última moda entres esses cientistas inteligentes e deu certo para as fábricas de sapato na China, não deu?

O resultado são fábricas de software funcionando (ou tentando funcionar) igualzinho a fábricas de sapato. Os programadores que dão o azar de ser tratados como máquinas de costura esperneiam de um lado dizendo que esta é a pior idéia desde a bola quadrada e os pesquisadores esperneiam do outro dizendo que o conceito deles de fábrica na verdade é uma boa idéia que não tem nada a ver com aquilo. Enquanto isso os leitores de títulos continuam a construir mais fábricas segundo seu próprio conceito para perpetuar a confusão.

Boa parte disso tudo simplesmente por causa de uma analogia que foi levada longe demais.

Toda equipe que desenvolve software já deve ter descoberto que “o entendimento dos requisitos deve ser alcançado.” Eles podem ter lido isso em algum lugar ou simplesmente enxergado algo que é óbvio demais para ser ignorado por qualquer mente saudável. Não importa como chegaram a tomar conhecimento disso, o importante é que qualquer pessoa que se propõe a resolver o problema de outra sabe que precisa entender razoavelmente bem o que está querendo solucionar. A questão interessante é desenvolver uma maneira eficiente de fazer isso.

Uma alternativa que faz muito sentido é tentar escrever e assinar junto com os clientes um belo documento que descreva detalhadamente os requisitos. Esta estratégia parece bastante natural porque a maioria das pessoas já está bem familiarizada com assinaturas e contratos. Afinal não é exagero dizer que este tipo de formalização vem sendo usado há séculos nos mais variados campos de atividade.

Por causa disso não é muito intuitivo pensar que esta abordagem tem um alto potencial para falta de entendimento. Como as coisas estão somente descritas e não há algo realmente tangível para guiar as opiniões, o entendimento depende totalmente da interpretação do texto e é possível que cada uma das partes tenha uma idéia diferente do objeto do acordo na hora da assinatura. Para que um acordo verdadeiro seja firmado, é essencial que ambas as partes estejam pensando na mesma coisa. Sem isso o máximo que se consegue é uma ilusão. Por causa do papel crucial da interpretação do texto, é comum que este tipo de engano ocorra ao usar apenas documentos. Apesar disso as assinaturas geralmente são aceitas como evidências de acordo.

Documentos fazem muito sentido quando o desenvolvimento do produto final precisa levar muito tempo. Quando isto é verdade o registro por escrito dos requisitos é uma opção aceitável. Há o risco de um acordo ilusório, mas ele é menos prejudicial para ambas as partes do que o cancelamento da empreitada. Porém quando os requisitos podem ser suficientemente pequenos e a equipe tem um processo de desenvolvimento suficientemente enxuto, as necessidades do cliente podem ser identificadas na segunda-feira e estarem materializadas em software rodando na sexta-feira seguinte (se é que software pode ser materializado). Quando isto é possível não faz mais sentido utilizar documentos e correr o risco de um falso acordo porque o produto final pode ser usado como objeto do acordo.

Software em execução é a forma mais incontestável de entendimento dos requisitos. Ninguém pode dizer que a equipe de desenvolvimento e o cliente não estão de acordo quando eles concordam sobre o produto final. Não há mais o que refinar, portanto não há mais onde discordar.

Você já deve ter visto muita gente copiar e colar código deliberadamente quando um pouco de senso crítico e abstração resolveriam facilmente o problema. Eu sei que eu já vi e o argumento para tamanha aberração tem sido sempre parecido: “Cara, eu e você sabemos que é melhor extraírmos o comportamento comum deste outro modo e que dá para enxugar o código desse outro jeito. Mas infelizmente não somos só nós dois que vamos trabalhar neste sistema. Acho que desse modo repetitivo fica mais fácil para o restante do pessoal que não é tão brilhante quanto a gente. Além disso, precisamos preparar a aplicação para ser mantida por qualquer tipo de idiota que a empresa resolva contratar no futuro.”

A idéia é bastante simples e, de um certo ponto de vista, parece até lógica: eliminar todo tipo de conceito que uma pessoa com uma semana de treinamento não vá entender. Assim é possível maximizar a quantidade de código que elas serão capazes de produzir, pois não vai ser preciso parar para aprender esses tais padrões de projeto e demais conceitos abstratos complicados que os concorrentes tanto usam. Pessoas pouco treinadas têm a tremenda vantagem de serem baratas. Deste modo, pode-se pagar bem pouco para cada programador e amontoar tantos quanto possível em grandes fazendas de cubículos para vomitar código repetido à maior velocidade possível. A maioria do código não vai servir para muita coisa, mas como a quantidade de gente à disposição é bem elevada, com um pouco de sorte dá até para produzir algo que o departamento de vendas consiga vender como útil. Quando nosso esquema estiver funcionando, podemos dizer que é uma “fábrica” e achar tudo muito bonito.

Eliminar todo tipo de conceito abstrato para permitir que qualquer pessoa com um mínimo de instrução possa trabalhar no sistema pode até parecer racional. Esse tipo de argumento é muitas vezes invocado em nome de algo que se chama de “pragmatismo”. Esta palavra está na muito na moda recentemente e, como toda boa palavra da moda, não são raras as vezes que é invocada do limbo apenas para defender uma idéia falida. O fato é que, sendo pragmatismo ou não, estas iniciativas servem muito bem ao intuito de nivelar a capacidade da equipe.

Por baixo.

Ao invés dos programadores mais versados na arte da escrita de código serem encorajados a passar seu conhecimento aos demais, eles são obrigados a correr com uma bola de chumbo amarrada aos pés para não ultrapassarem os outros. Eles perdem toda a energia que o design elaborado os proporcionava para que os demais possam continuar lentamente. Não gosto nem de imaginar o que isso pode fazer com a auto-estima deles e, conseqüentemente, com o futuro do projeto.

Em dois artigos recentes, Vitor Pamplona argumenta contra a busca do Santo Graal da Orientação a Objeto e preciso dizer que este argumento me parece bastante razoável. Mas como todo bom argumento ele pode ser interpretado de forma extrema e levar uma equipe a abominar completamente os objetos e padrões de projeto. Eles podem passar a considerá-los simples mecanismos para tornar uma aplicação mais difícil de entender. Apenas uma tentativa patética por parte dos mais escolados de manter a equipe dependente de seu conhecimento.

Esta opinião extrema parte do pressuposto falho que objetos e padrões são mais complicados do que código seqüencial, repetido e bagunçado em geral. Aqui é onde encontramos o principal ponto de discordância entre os que defendem o código elegante e os que estão do lado da bagunça compreensível. Ambos defendem que o seu estilo é mais legível. Os últimos simplesmente por empregar conceitos mais simples e os primeiros por dedicarem mais tempo aos aspectos estéticos do código.

Código que não é legível não é elegante. Se for preciso vagar por toda a base de código para entender a idéia geral de uma única linha, não importa a densidade de padrões de projeto por metro quadrado: o código é deselegante. Por outro lado, se preciso consertar um defeito sutil relacionado à mesma linha, espero que deva ser preciso dar uma olhada em uma quantidade razoável de código além dela. Mas quando estou apenas lendo, não.

Isso não quer dizer que código precise ser simplista para ser legível. Quando alguns conceitos um pouco mais elaborados são usados dentro de um contexto específico, podem tornar o código muito mais legível que a alternativa simplista. Tome como exemplo as interfaces fluentes. Muita gente ainda não ouviu falar delas, mas poucos fariam muito esforço para entender esta linha caso a encontrassem num teste:

mock.expects(once()).method("m").with("hello")


Apesar disso este pequeno trecho de código está fazendo uso de pelo menos um padrão de projeto (nominalmente o Builder) e de um estilo de código ao qual nem todo mundo foi formalmente apresentado (uma interface fluente). Este trecho é legível apesar de não ser nada que um novato escreveria. Ele funciona porque os conceitos são aplicados onde fazem sentido.

A encrenca começa a aparecer quando os garotos dos padrões entram em cena forçando soluções inadequadas para os problemas errados, fazendo de tudo para encaixar um cubo em um buraco com forma de círculo. Ou pior: quando eles começam a inventar problemas só para aplicarem suas soluções preferidas.

O título era para ser outro. Algo como “Você batiza suas sugestões de funcionalidade, pedidos de mudança, tickets, estórias de usuário ou seja lá como você gosta de chamar as solicitações de melhoria para suas aplicações?”, mas acho que ficaria um pouco longo demais. Resolvi generalizar tudo para “bugs”, mas por favor não se irrite se não escolhi seu termo favorito. Com uma lista de termos tão longa quanto essa, é difícil conseguir agradar a todos.

Uma vez trabalhei junto com alguns amigos em um jogo. Um jogo é só um programa de computador e, assim como qualquer programa de computador, acaba adquirindo alguns defeitos durante o desenvolvimento. A peculiaridade dos jogos é que eles costumam imitar o mundo real, tornando mais fácil fazer associações e analogias.

Nosso jogo tinha alguns defeitos particularmente interessantes. Um deles fazia com que alguns personagens começassem a se deslocar em uma direção que não coincidia com a animação exibida. Dava para ver o boneco tentando andar na diagonal enquanto o deslocamento real era na horizontal. Ficávamos entretidos olhando aquilo e acabamos inventando um nome para o defeito: Moonwalker, uma referência ao passo de dança popularizado por Michael Jackson.

Outro defeito tinha a ver com liberação de memória. Em algum ponto do código, estávamos liberando erroneamente a memória usada para armazenar os quadros da animação do movimento dos personagens. Isso de vez em quando fazia eles desaparecerem da tela por alguns milésimos de segundos e reaparecerem em outro ponto mais à frente. Chamamos isto de Tele-transporte. Um terceiro defeito, desta vez na rotina de detecção de colisão, fazia com que o personagem principal pudesse atravessar as paredes em alguns pontos. Este foi prontamente batizado com o nome “Ladrão Fantasma”.

Deixando a nostalgia de lado por um momento, o fato é que os nomes humanizavam todo o trabalho desde a detecção até a eliminação dos defeitos, do mesmo modo que os nomes de domínio humanizam os endereços na Internet (e as pessoas acabam usando os mecanismos de busca para levar a idéia ainda mais adiante). Para um computador é simples enviar uma requisição para 200.186.109.162, mas para uma pessoa é mais simples entrar no blog.thiagoarrais.com.br (e muita gente acha ainda mais simples buscar por “Mergulhando no Caos”). Do mesmo modo, pode ser natural para uma máquina marcar como resolvido o registro referente ao bug #1376, mas para um humano é mais natural levantar do lugar e dizer “Consertei o Moonwalker”.

O Motiro institucionaliza esta prática. Os “bugs” nele são chamados “sugestões de recurso” e toda sugestão de recurso é uma página wiki. Como qualquer outra página wiki, elas têm um título: um nome que precisa ser informado por quem registra ou edita um bug. Se a pessoa não estiver se sentindo muito criativa na hora, pode deixar de preencher o título e a página receberá um número.

Os demais sistemas de acompanhamento de que tenho notícia costumam usar um número para se referir aos bugs e disponibilizam um sumário para humanizar um pouco a coisa. O Motiro é o único que conheço que elimina os números de bug em favor dos títulos. O fato de nenhum outro sistema do tipo fazer isto pode significar duas coisas: ou esta é uma daquelas idéias que parecem ridiculamente óbvias depois que alguém as têm (como o Ovo de Colombo), ou é uma péssima idéia mesmo.

Se você parar para pensar, defeitos são coisas que se quer eliminar o mais rápido possível. Algo que você não quer andando por aí durante muito tempo. Se uma barata aparece na sua cozinha, você vai lá e mata. Não fica inventando nomes fofinhos e engraçadinhos para a intrusa. Se os defeitos são detectados e corrigidos rapidamente, não faz muito sentido perder tempo bolando nomes.

Por outro lado, os recursos para eliminação de defeitos são limitados. Pode ser que o chinelo não esteja por perto na hora que a barata aparece, pode ser que você tenha um pavor gigantesco de baratas e não consiga fazer nada além de gritar e correr ou pode ser que você precise estudar bastante antes de entender alguma tecnologia. Quando não é possível corrigir todos os defeitos ao mesmo tempo, alguns deles precisam existir por mais tempo que os outros e podem ganhar nomes.

Além disso, bugs neste contexto não são somente defeitos. Podem ser também sugestões de novos recursos e comentários para melhoria. Neste caso, também volta a fazer sentido batizar estas coisas. Algumas dessas sugestões podem precisar ser amadurecidas e um nome é uma boa forma de se referir a elas.

De qualquer modo, o fato de nenhum sistema atual favorecer as palavras em detrimento dos números é intrigante. Afinal, pessoas geralmente lembram melhor das palavras do que dos números, não?

E você? Costuma batizar seus bugs?

Provavelmente vou mexer em um vespeiro dos grandes com o texto de hoje. Pelo menos é o que eu vejo acontecer quando alguém resolve desafiar, questionar ou simplesmente comentar qualquer coisa no campo da Agilidade (com letra maiúscula mesmo). Neste pequeno mundo, você nunca sabe quando está mexendo com alguma coisa sagrada para alguma pessoa. Também é o que eu vejo acontecer quando programadores discutem a questão traduzir ou não traduzir. Então parece que são dois vespeiros ao invés de um só. Mas eu gosto de exercitar a iconoclastia sempre que possível e vou continuar com o texto apesar de tudo.

Não sei como surgiu a tradução que parece ser normalmente usada por todo mundo aqui pelas bandas do Brasil para “Test Driven Development”, mas eu simplesmente não consigo evitar um certo incômodo mental quando alguém cita “Desenvolvimento Orientado a Testes”.

Pronto falei. Podem jogar as pedras.

Não é que os símbolos tenham algum papel extremamente relevante quando usados por pessoas com o mesmo domínio sobre o vocabulário. Evidentemente, não há nenhum problema nas palavras em si quando as pessoas sabem do que se está falando. Mas é quem não sabe que me preocupa.

Esta expressão “orientado a” deve ter vindo do mesmo baú do qual foram tirados alguns outros termos da moda como Programação Orientada a Objetos e Arquitetura Orientada a Serviços (que, como todo bom modismo, também costumam ser completamente mal interpretados). Não vou recorrer ao lugar comum de consultar um dicionário, mas este termo pode levar muita gente a pensar em simplesmente atentar para os testes e projetar sistemas testáveis. Esta postura certamente é melhor que não dar atenção nenhuma aos testes e relegar a atividade ao décimo-oitavo plano para ser realizada um pouco antes da implantação no caso de sobrar algum tempo. “Desenvolvimento Orientado por Testes” é um pouco menos ambíguo. Mas prefiro “Desenvolvimento Guiado por Testes” tanto por ser mais fiel ao original quanto por eliminar o já sobrecarregado termo “orientado”.

Desenvolvimento guiado por testes envolve uma certa atenção aos testes, mas também uma porção de outras escolhas técnicas e filosóficas. Envolve obrigatoriamente escrever os testes antes do código. Afinal, você não pode ser guiado por algo que não existe. Quando se abraça esta filosofia, os testes acabam virando uma das principais razões da existência do código, logo abaixo das necessidades do usuário. Certamente estas últimas são muito mais importantes do que os primeiros, mas um conjunto de testes bem projetado será o melhor reflexo das necessidades do usuário.

Mas, como disse, sou um iconoclasta atento e não acho que este tipo de posicionamento mental seja ideal para todos os casos. Particularmente, quando estou investigando algum tipo de tecnologia que imagino que vou precisar e com a qual ainda não tenho muita familiaridade, prefiro desenvolver apenas orientado a testes. Mantenho sempre a mente atenta à testabilidade, mas não necessariamente chego a escrever os testes. Depois que consigo algum domínio sobre a tecnologia, costumo voltar ao desenvolvimento guiado por testes e faço tudo que posso para escrever os testes antes do código de produção.

De qualquer modo, os termos em si não são tão importantes. São apenas símbolos e, se usados no contexto correto, não costumam gerar nenhum tipo de confusão. O importante são as diferenças filosóficas denotadas por eles.

Acho que minha doidice por linguagens de programação está começando a gerar uma doidice por linguagens naturais. Vai saber…

Todos nós já experimentamos. Alguns se arrependem e outros nem tanto. Alguns conseguiram encontrar um modo de se livrar e outros nem tentaram. Mas quase todo programador já trabalhou em “modo cego”.

Por meses seguidos.

Saber quando uma equipe está trabalhando em modo cego é fácil: é só perguntar quanto tempo faz desde que receberam algum tipo de comentário de um usuário final. Mais de um mês é um bom sinal de que estão ficando cegos. O tempo exato depende muito do tipo de aplicação que estão desenvolvendo, mas um mês geralmente é tempo demais para andar sem saber para onde vai. Além disso, não faz mal lembrar que um representante do usuário é melhor do que nada, mas não é páreo para um usuário de verdade.

Evitar entrar em modo cego também é fácil: basta estipular um prazo curto e entregar a aplicação do modo como estiver quando a data chegar. Durante este período a equipe exercita simultaneamente todas as habilidades que os aspirantes a desenvolvedor de software tão sabiamente estudam nas suas escolas, de modo a ter sempre algo usável. Fazer isso dá trabalho porque é preciso tomar algumas providências para garantir que a aplicação esteja pronta para ser entregue a todo momento. Afinal, a equipe certamente não vai querer chegar à data combinada sem ter algo apresentável. Mas não é nada humanamente impossível.

Apesar da atenção precisar ser redobrada, o resultado compensa. O usuário poderá oferecer seus comentários depois de ter colocado as mãos em algo concreto. Qualquer forma de tentar artificializar esta experiência através de documentos de especificação, apresentações elaboradas ou emaranhados de diagramas com certeza não oferecerá a mesma expressividade.

A possibilidade de receber continuamente comentários e sugestões de qualidade funciona como poderoso combustível para o potencial da equipe. Quando esta força energizante está disponível, há mais chance de se obter o sucesso. Há mais chance para vencer. Porém, como os períodos de iteração são curtos, estas vitórias serão necessariamente pequenas. Não há tempo para fazer nada muito grandioso e será necessário saber acumular estas pequenas vitórias ao longo do tempo para atingir uma vitória maior.

Ciclos curtos permitem que sejam alcançadas pequenas vitórias. Fracassos vão inevitavelmente se interpor no caminho da equipe, mas também serão pequenos. Estarão contidos em um período suficientemente pequeno para que não causem grande estrago e as vitórias serão tão mais freqüentes que eles passarão quase desapercebidos. Uma vitória pequena puxa a outra, e uma derrota pequena não faz muita diferença. Assim o moral da equipe é estimulado e o sucesso é naturalmente atraído. Ciclos longos, por outro lado, permitem causar grandes surpresas. Quando se trabalha muito tempo sem divulgar sua evolução, o resultado só pode ser grandioso. Se for um sucesso, será uma vitória estupenda. Mas a maior chance é que seja uma derrota miserável.

Porém há ainda quem sinta falta das vitórias extravagantes ou pelo menos do alívio de saber que acabou de deixar uma quantidade monumental de trabalho para trás. Muitas equipes que trabalham às cegas durante muito tempo costumam comemorar estrondosamente as entregas. Mesmo quando são tremendos fracassos comemorar é natural simplesmente porque todos acabam de se livrar de um fardo bastante pesado. Com ciclos curtos, esse sentimento se perde. Não faz muito sentido comemorar a entrega de uma semana de trabalho. Ao fim de dois meses, uma equipe com ciclos de uma semana provavelmente vai ter uma vitória acumulada muito maior do que uma equipe com um único ciclo de dois meses. Apesar disso, a segunda vai comemorar muito mais.

Usar prazos curtos para as entregas é uma boa forma de garantir que elas sejam vitoriosas. Pequenas vitórias, mas vitórias.

O mundo todo é formado a partir de coisas pequenas. Não importa quão grande seja a casa daquele novo figurão, ela precisa ser construída tijolo a tijolo. Enxames são feitos de pequenas abelhas, países são feitos de cidadãos e mercados são feitos de negociantes. No entanto, o resultado final do conjunto em todos os casos é um conglomerado grandioso e costuma ser considerado uma entidade única por vários motivos, que vão do retórico ao pedagógico. Fica difícil ver a floresta inteira quando se está no meio das árvores. Para entender o todo, precisamos ignorar por um momento as partes e analisar o conjunto como uma entidade única.

Isso é importante em muitas situações e não há como negar que o homem só chegou onde está por ter desenvolvido essa capacidade. Mas estamos acostumados a partir das partes para o todo. Estamos acostumados a sintetizar. O perigo mora no caminho inverso: tratar o todo como um entidade indivisível e esquecer que para mudá-lo é preciso dispensar muita atenção para as partes.

Quando uma empresa precisa melhorar sua capacidade de produção ou velocidade de resposta, uma das piores coisas que se pode fazer é tentar projetar e aplicar uma metodologia qualquer que trate a organização inteira como uma grande equipe. Tudo que uma grande organização menos precisa é de uma metodologia para uma equipe de centenas de pessoas. O que ela precisa na verdade é de centenas de equipes de poucas pessoas. Não é preciso achar uma metodologia gorda e formar uma equipe gigante, mas formar equipes pequenas e arrumar metodologias enxutas.

Necessariamente nesta ordem.

Todo mundo já ouviu falar que formas ágeis de trabalho funcionam melhor para equipes pequenas e há quem prefira abordagens mais peso-pesado justamente por este motivo. O interessante é que isto não é uma fraqueza. Qualquer abordagem para coordenação de pessoas funciona melhor com equipes pequenas. Portanto, ter equipes grandes não é motivo para evitar uma abordagem ágil. Os grupos de trabalho simplesmente deveriam ser menores. Grupos pequenos conseguem se organizar e comunicar-se mais facilmente do que grupos grandes simplesmente porque há menos gente para coordenar. Se você tentar reunir mais de duas pessoas para escolher um único prato em um restaurante novo, vai saber do que estou falando.

Equipes pequenas costumam vencer as grandes no quesito adaptabilidade. O pequeno e simples é mais rápido para se adaptar. Bactérias, por exemplo, são extremamente adaptáveis justamente por serem criaturas bem simples. São capazes de se reproduzir e evoluir tão rapidamente que os médicos precisam evitar prescrever os mesmos antibióticos por períodos prolongados para uma mesma população a fim de evitar que elas se acostumem à droga e evoluam para algum tipo de super-bactéria resistente à medicação. A capacidade de adaptação delas é tamanha que “períodos prolongados” aqui são medidos no máximo em algumas dezenas de anos, ao contrário dos vários milhares de anos necessários para a evolução de organismos mais complexos como o homem. O mesmo ocorre com equipes pequenas. Na presença de uma adversidade ou mudança de ambiente, elas podem mudar de rumo muito mais rápido que uma equipe com algumas dezenas de pessoas.

Tem um tipo de blog pelo qual tenho uma ojeriza tremenda: o blog-diário. Acho que eles já pararam de fazer isso (porque migraram para os sites de relacionamento), mas sabe aqueles blogs de adolescentes cujos artigos costumam ser sobre a festinha de ontem ou a bronca que o professor passou na turma hoje mais cedo? Sabe aqueles blogs cujos artigos mais elaborados são aqueles que têm uma letra de música qualquer que o autor e seus amiguinhos estavam escutando no dia (e mais nada)?

Este tipo de coisa não acontece somente com garotos e garotas de 14 anos, alguns blogueiros na área de tecnologia também estão infectados com a mesma doença. Neste caso os assuntos mudam um pouco. Passam a ser sobre o último release dos seus projetos, as conferências mais badaladas e os encontros de grupos de usuários locais. Eles podem não notar, mas estão agindo do mesmo modo que os adolescentes. Estão somente publicando um diário de bordo.

Acho que blogs deveriam ser um meio para publicar opiniões e vê-las serem destrinchadas, atacadas e testadas. Se estivéssemos em uma revista semanal, os blogs deveriam ser mais como uma coluna ou um editorial do que como o resumo da semana. Os leitores não querem saber o quanto o autor é inteligente, produtivo ou como tem sucesso em tudo que resolve fazer. Ao invés disso, um blog deve ser um espaço para o autor ajudar os leitores a se tornarem mais inteligentes, produtivos e a terem mais sucesso em tudo que resolverem fazer.

Apesar disso tudo, acabei caindo nesta armadilha em conseqüência da correria nossa de cada dia. Se você consultar os históricos aqui do blog, vai ver que os dois últimos artigos anteriores a este se encaixam perfeitamente no que eu descrevi como artigos de blog-diário. O último é só um anúncio de reunião de grupo de usuários e o penúltimo uma bela de uma babada em meu próprio trabalho juntamente com o anúncio da publicação do Motiro (não consegui resistir a mais um link). Mas o sinal mais alarmante de que eu estou usando meu blog como um diário é que este mesmo artigo que você está lendo agora também é só mais uma anotação de diário.

Sim, eu publiquei toda esta introspecção e fiz você ler até aqui somente para anunciar que participei da entrevista que o Eduardo Fiorezi fez com o Vitor Pamplona. Foi bastante gratificante receber um segundo convite para o programa do Eduardo, principalmente por ter sido surpreendido com uma posição de entrevistador ao invés de entrevistado e pela estrela do programa ser uma figura tão relevante.

Espero que com estes três últimos artigos eu não tenha perdido metade da minha audiência, mas prometo que vou fazer de tudo para que o próximo revele algum pensamento interessante sobre tecnologia.

Por enquanto, um anúncio de entrevista disfarçado de reflexão é tudo que tenho a oferecer.

Estávamos pensando em organizar um encontro de usuários Ruby em Recife e depois do ótimo artigo da Kathy Sierra ressaltando a importância do contato cara-a-cara não podemos mais deixar para depois. A idéia é que depois dessa pequena reunião inicial possamos começar a formar um grupo de usuários local para estudarmos juntos, organizar palestras e fazer começar aquele negócio que falam tanto por aí chamado de comunidade. Com um encontro presencial nos fortalecemos e juntos podemos ajudar melhor quem está querendo aprender.

O encontro será na próxima quarta-feira (dia 21) à noite no bar Recanto Paraibano no Parnamirim. Precisamos saber mais ou menos quantas pessoas vão aparecer para dimensionarmos o local. Quem for de Recife e estiver interessado em participar, pode me responder em particular (meu e-mail fica no GMail: thiago ponto arrais) para nos organizarmos. Dependendo da participação, talvez precisemos alugar o Chevrolet Hall ou coisa do tipo.