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.

Dia desses montei uma máquina nova para mim. Ela tem um desses processadores pomposos de núcleo duplo que já deixaram de ser os artigos de luxo que eram há alguns anos. Minha máquina anterior tem um processador de núcleo simples da época em que os de núcleo duplo tinham preços proibitivos. Este núcleo solitário trabalha a uma freqüência de 1.8GHz enquanto os dois núcleos da máquina nova rodam a 2.2GHz. Acho que a diferença é suficientemente pequena para que possamos dizer que a freqüência é mais ou menos a mesma. Os ganhos de performance, portanto, devem ser proporcionados principalmente pela presença dos dois núcleos e não do aumento de freqüência.

Porém a máquina nova não parece ser muito mais rápida que a antiga. Obviamente ela se sai muito melhor que a anterior quando há vários processos rodando ao mesmo tempo. Mas quando preciso que ela execute um programa único, a performance é mais ou menos a mesma. Por um lado, é verdade que o gargalo da maioria das aplicações realmente não está no processador nem na memória, mas nos dispositivos de entrada e saída como rede e disco. Para estas aplicações é de se esperar que um aumento da capacidade de processamento não faça grande diferença. Por outro lado, esta máquina nova não parece mais rápida nem para atividades com uso intenso do processador.

Em nome da boa e velha curiosidade, resolvi fazer um teste rápido. Peguei um dos meus CDs de música e coloquei a máquina para compactar uma amostra razoável de áudio. Compactação de áudio (e vídeo) é uma daquelas tarefas ridiculamente paralelizáveis. Uma forma bastante óbvia de aproveitar melhor o hardware seria deixar que cada um dos processadores ficasse responsável pela compactação de metade do trecho de áudio. Apesar disso, quando estava compactando o áudio, observei que apenas um dos núcleos fica em uso em um dado momento. De vez em quando o processamento é transferido de um núcleo para outro, mas apenas um é usado efetivamente.

Quando há vários processos diferentes brigando por um pouco de tempo de processador, os sistemas operacionais modernos são bastante espertos para distribuírem a carga inteligentemente. O problema acontece quando há um programa que demanda muito do processador mas não está preparado para ser quebrado em partes menores e executado em paralelo. Se ele não usa nenhum mecanismo para identificar os trechos de código que podem ser executados lado a lado, o máximo que o sistema operacional pode fazer é enxergá-lo como um grande amontoado de instruções a serem executadas uma após a outra. Chegamos a um ponto em que os sistemas operacionais estão prontos e o hardware também está pronto, só faltam as aplicações.

Máquinas com múltiplos processadores já são realidade há um bom tempo e o uso de vários núcleos por chip não é tão novo assim, mas este tipo de tecnologia estava limitado a certos nichos. A preocupação em utilizar o poder de vários processadores operando em paralelo só começa a se popularizar agora que a festa seqüencial acabou. Antes não fazia muito sentido dar-se ao trabalho de escrever programas paralelizáveis porque era possível fazê-los executar de forma mais rápida simplesmente enfiando mais alguns megahertz nos processadores. Porém agora o limite da freqüência, e principalmente da dissipação do calor associado, parece ter sido atingido e, por mais que esperemos, não vai dar mais para comprar processadores que operem a freqüências muito maiores que as atuais.

Meu palpite é que, de agora em diante, quem precisar melhorar a performance de suas aplicações utilizando todo o hardware disponível (o que não se aplica a todo mundo, afinal a “otimização prematura é a raiz de todo o mal”) vai precisar escrever programas paralelos. Na verdade, eu acho que as pessoas já estariam escrevendo programas paralelos há muito tempo se fosse mais fácil. Só que os ambientes para desenvolvimento mais populares de hoje não são muito amigáveis para este tipo de programa. As plataformas mais usadas ainda fazem uso de alguns conceitos que se mostraram bem difíceis de digerir, como threads e semáforos.

Isso quer dizer que precisamos descobrir novos modelos de pensamento se quisermos trabalhar com código concorrente e paralelo. Se você me permitir outro palpite, posso arriscar dizer que os modelos mais eficientes do futuro não vão ser tão seqüenciais quanto os atuais.

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.

Então parece que a Apple está preparando uma versão do seu navegador Safari para Windows. Parece também que o bicho está disponível como beta e, como tenho acesso a uma máquina Windows XP no trabalho, achei que não faria mal a ninguém testar o navegador que há algum tempo atrás era exclusividade de usuários Mac. Claro que o primeiro site que testei foi o do projeto Motiro e o resultado não foi muito animador:

Os trechos de texto com alguma modificação de estilo (títulos, negrito, cores personalizadas) não foram exibidos e houve alguns problemas de perda de alinhamento em alguns elementos. Isso tornou o site totalmente inútil para qualquer pessoa com um mínimo de juízo (como não sou uma dessas pessoas, ainda tentei abrir algumas páginas da wiki e parece que os problemas continuam em todas as páginas).

Há algum tempo venho usando o BrowsrCamp.com para ver algumas fotos de como o Motiro aparece no Safari. Obviamente que ver fotos estáticas do seu site não é uma opção tão boa quanto vê-lo ao vivo, mas é melhor do que nada. A versão que eles usam não é este beta do Safari 3, mas um Safari 2 que presumo ser estável. Nele o Motiro aparece bem mais apresentável:

Será que o Safari mudou tanto do 2 para o 3 que passou a renderizar sites de modo completamente diferente? Ou este é um comportamento apenas da versão Windows do Safari 3? Se alguém tiver um Mac por aí e puder fazer estes testes com o Motiro, eu agradeceria muito. Depois dessa estou pensando seriamente em concentrar os esforços completamente nos aspectos de compatibilidade com navegadores para o release 0.6.7.

Parece que a Microsoft anunciou esta semana a nova versão do Visual Studio. Antigamente ele era um ambiente de desenvolvimento, mas agora parece que vai ser uma plataforma para várias aplicações. Pelo que pude encontrar de cobertura on-line, parece que agora eles querem produzir uma plataforma extensível para ferramentas de desenvolvimento. A idéia básica é usar o alicerce do Visual Studio para construir aplicações como plugins. Mais ou menos como o Eclipse vem fazendo desde os tempos memoráveis da versão 2.0, lá pelos idos de 2002. Qual será a próxima? Construir aplicativos de propósitos diversos sobre a plataforma Visual Studio? Algo como Eclipse RCP, que está disponível desde a versão 3.0 (que saiu mais ou menos em 2004)?

Ian Skerret, diretor de marketing da Fundação Eclipse está mais do que certo em afirmar que a cópia é a forma mais sincera de admiração. Todas as organizações e indivíduos que formam a comunidade de desenvolvedores da plataforma Eclipse devem estar lisonjeados. Afinal de contas quando os seus competidores mergulham com tanta vontade nesse tipo de perseguição gato-e-rato, eles estão involuntariamente dizendo que você estava certo o tempo todo.

Os fornecedores externos interessados em construir sobre esta nova plataforma devem estar ansiosos para que a brincadeira continue. Talvez eles consigam um pouco do ambiente colaborativo, da abertura e da flexibilidade que o Eclipse já experimenta há anos. Porém, tendo em vista os recentes desdobramentos do caso TestDriven.NET, parece que isso não vai acontecer muito cedo.

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.