Um laboratório agile a céu aberto

Se você apresentar o agile a um desenvolvedor experiente hipotético que ainda não o conhece, é bem possível que a reação seja: “tá, mas você só tá dando um nome ao que a gente já faz.”

É uma reação natural, afinal de contas agile é exatamente isso desde o início. O próprio manifesto foi escrito por desenvolvedores experientes para botar um nome naquilo que eles já estavam fazendo. As abordagens incrementais onde o software funcionando é a principal ferramenta de comunicação com o cliente tinham surgido independentemente várias vezes. Esse tipo de abordagem é o que os desenvolvedores adotam naturalmente se forem deixados em paz.

Isso é ótima notícia para quem já é experiente: para estar por dentro dessa buzzword basta continuar trabalhando normalmente. Mas e para quem está começando e quer aprender? E para quem sempre foi forçado a trabalhar com um modelo cascata e quer aprender? Seria ótimo se existisse algum tipo de fazenda de formigas onde você pudesse soltar um monte de devs, não impor restrições e ver como eles naturalmente se organizam. Onde você pudesse ver os devs agile trabalhando e aprender com eles.

Boa notícia para quem quer aprender: isso existe! E o nome é comunidade open source.

O open source de hoje já tem muito mais suporte corporativo do que o de dez ou quinze anos atrás. E junto com o suporte vem a interferência. Mas felizmente os projetos de hobby não são tão difíceis de encontrar. Até mesmo os projetos com suporte corporativo são bastante espelhados nos projetos de hobby. Ninguém quer contribuir com um projeto burocrático, então ou eles imitam os hobbistas ou simplesmente não recebem contribuições.

Um projeto de hobby é um exemplo perfeito de deixar os desenvolvedores em paz para se organizarem naturalmente: como estão fazendo algo porque querem, e não porque tem alguém pedindo ou pagando, o modo como vão se coordenar vai ser escolhido para beneficiar eles próprios. A partir deste modo de pensar emergem práticas atualmente identificadas com o agile. As práticas são interessantes, mas o mais importante é estar inserido nesta mentalidade. Porque é a partir dela que as práticas podem ser avaliadas criticamente e é a partir dela que novas práticas surgem.

Um dos princípios do manifesto agile mais claramente adotado pelos projetos open source é o “software em funcionamento mais que documentação abrangente”, traduzido diretamente no “talk is cheap, show me the code” do Torvalds. Ninguém vê um projeto open source que passa meses “levantando requisitos” e escrevendo documentação antes de escrever ao menos uma prova de conceito ou um protótipo do sistema final. Há sempre uma versão que roda do sistema. Depois que os projetos começam, cada um dos commits modifica um pouco o código, mas sempre se mantém o sistema rodando. Não se quebra o build em projetos open source. Não se quebra o build em projetos agile.

Temos na comunidade open source um laboratório de agile a céu aberto com as portas escancaradas. Todo esse processo pode ser observado e esmiuçado por quem quer aprender. Basta fuçar as pull requests, bugzillas e gits da vida. A fazenda de formigas está aí. Basta ter a curiosidade de olhar.

(À propósito… Eu usei o tempo todo agile com ‘A’ minúsculo porque o Agile com ‘A’ maiuscúlo é um termo extremamente sobrecarregado hoje em dia. Não estou falando de práticas específicas, de reuniões de pé, de TDD, nem de quadros com post-its. Estou falando do mentalidade ilustrada pelo manifesto. É triste isso de termos que deixar de usar a palavra que escolhemos para nomear este mentalidade, mas infelizmente é o estado em que nossa indústria chegou.)

Programar deveria ser fácil

Em julho deste ano, os físicos do LHC anunciaram a descoberta de uma nova partí­cula consistente com o bóson de Higgs. Eu não entendo nada de nada sobre física de partÃículas, mas gosto de acompanhar as descobertas da área para tentar absorver um pouco do entendimento que esses super-humanos têm da natureza. Quando soube do anúncio, não pude deixar de pensar que são essas pessoas que estão fazendo o trabalho duro de verdade.

Eu, aqui programando regras arbitrárias e tentando formar um universo artificial consistente? Nem tanto. Comparado com o trabalho desses caras, o meu é muito fácil. Mesmo porque na maioria das vezes minhas regras não se encaixam tão bem assim e passam longe de ser consistentes.

Até se trabalhássemos sempre para fazer programas totalmente consistentes e sem defeitos, nosso trabalho como programadores deveria ser mais fácil do que é. Mas porque tanta gente acha que programar é difícil?

Vamos voltar à Física por um instante. O objetivo de um físico é descrever as regras da natureza da forma mais simples possível. Há um conjunto de regras que já existe e funciona muito bem e eles tentam fazer a engenharia reversa do universo inteiro. Eles não possuem nenhuma documentação, diagrama, esquema ou planta fundamental além do que aquilo que os físicos anteriores descobriram. Para deixar a coisa mais complicada ainda, nem nessas descobertas anteriores eles podem confiar cegamente. A física newtoniana, por exemplo, não funciona nem nas escalas quânticas nem nas velocidades próximas à da luz. E eles tiveram que descobrir isso quebrando a cara.

O problema essencial é que há um conjunto de regras pré-estabelecidas que se quer conhecer.

Contraste isso com o Desenvolvimento de Software. Quando programamos, estamos definindo regras a partir do nada e temos controle total do funcionamento do “universo”. Sim, nós também precisamos subir nos ombros de gigantes e usar bibliotecas, frameworks e linguagens de programação que não fomos nós que inventamos. Mas as regras destas ferramentas que usamos também foram escritas do zero, tudo montado a partir de uma álgebra fundamental de bits. O que nós tentamos fazer é justamente o contrário que os fí­sicos fazem. Enquanto eles partem de um conjunto de comportamentos observáveis para extrair as regras de funcionamento, nós escrevemos as regras de modo a gerar o comportamento.

Programadores definem como um universo em particular deve funcionar partindo de regras já conhecidas. Fí­sicos definem regras de modo a explicar um universo conhecido.

É como se os fí­sicos estivessem tentando decifrar o código-fonte de um programa sem ter acesso nem aos binários. Se fazer decompilação não é coisa simples, imagina ter que fazer isso só com o resultado de testes!

Tendo isto em mente, fica mais difícil ter alguma compaixão pelos programadores. Enquanto os físicos precisam enfrentar uma complexidade inerente ao objeto de estudo deles, toda a complexidade que enfrentamos ao programar é culpa exclusivamente nossa como classe. Obviamente às vezes também precisamos modelar objetos e processos do mundo real inerentemente complexos, mas essa é uma conversa para outra hora (e minha impressão é que muitas vezes tornamos o pedaço de mundo real que estamos tentando modelar mais complexo do que ele realmente é). O que importa é que fomos nós que criamos este monstro complexo ao não dar a devida atenção ao design. Enfileirar bits de modo que um computador consiga seguir as instruções é até fácil. Fazer isto elegantemente é que é difí­cil. E por negligenciar essa parte difícil não temos a facilidade que deverí­amos ter.

Bagunça pode ser tudo o que você precisa

Já notou que sempre bangunçamos o ambiente em que estamos trabalhando? Se você não fizer um esforço bem consciente para organizar tudo enquanto trabalha ou quando termina de fazer o que precisa, as chances são que as coisas estejam um pouco mais bagunçadas do que no início. Já notou também que mesmo que tudo pareça bagunçado, você (quase) sempre consegue se achar na sua bagunça? E que se alguém fizer o “favor” de “organizar” as coisas para você há uma boa chance de piorarem sua situação? Isso acontece porque a bagunça era a sua bagunça.

E também porque provavelmente não era uma bagunça.

Por trás desse tipo de bagunça aparente, há sempre uma ordem não óbvia. Para usar um exemplo bastante simples discutido no livro Uma bagunça perfeita de Eric Abrahamson e David H. Freedman (prometo publicar uma resenha apropriada em breve), uma pilha de papéis jogados sobre uma mesa está ordenada por ordem de uso: os mais usados ficam no topo e os menos usados no fundo. Isso acontece naturalmente se você sempre devolver os papéis que precisou da pilha para o topo. Do mesmo modo, se você pedir a alguém para realizar alguma tarefa rotineiramente, as pessoas sem nem perceber acabam bolando procedimentos de modo a facilitar o trabalho, aproveitar melhor o tempo e tornarem-se produtivas. Por isso bons programadores acabam chegando a algo parecido com XP se não forem podados.

Mas este é um blog sobre desenvolvimento de software para programadores e o trabalho do programador é justamente eliminar a bagunça do trabalho das pessoas, escrever programas que as ajudem a se organizar melhor, identificar “processos de negócio” e coisa e tal, certo?

Errado, se o seu ego conseguir aceitar que as pessoas que estão lá fazendo o trabalho no fim das contas sabem muito mais dele do que você.

Muitas vezes o que precisamos não é bem organizar o que as pessoas estão fazendo. Às vezes precisamos somente tornar a bagunça mais eficiente. Quando se tenta organizar muito os processos de trabalho das pessoas a coisa acaba ficando engessada demais. O resultado são sistemas que atrapalham mais do que ajudam e gente que passa mais tempo tentando agradar os sistemas corporativos do que resolvendo problemas dos clientes. Já ouviu a célebre frase “eu entendo, mas o sistema não deixa” quando tentou algo minimamente fora do comum com um banco ou uma operadora de telefone? É disso que estou falando. Resultado dos sistemas paralisantes. Resultado da organização demasiada.

Por outro lado sistemas caóticos terminaram sendo alguns dos exemplos de maior sucesso em nossa indústria. O Unix, por exemplo, é descrito por Martin Fowler como a maior aglomeração de coisas coladas umas nas outras que o mundo já viu. A web, por sua vez, é uma imensa bagunça de documentos, links e referências em escala global. Os dois sistemas têm em comum a filosofia de fazer pouca coisa, mas fazer bem o que escolheram fazer, e permitir que os usuários façam o que bem entenderem utilizando essa fundação. Eles não tentam organizar cada mínimo aspecto da rotina das pessoas. Eles aceitam o fato de que nunca vão conhecer o trabalho das pessoas tão bem quanto elas mesmas e se concentram em permitir que elas tenham liberdade para fazer o que quiserem do jeito que quiserem.

Todo programador deveria estar escrevendo jogos

Encomendei um livro chamado A theory of fun for game design de Raph Koster. Apesar do que possa parecer, eu não pretendo escrever jogos de computador num futuro próximo. Pelo menos não no sentido comum da palavra “jogo”. Então porque diabos eu iria querer ler um livro desses?

A resposta está estampada no título do livro: uma teoria da diversão. Este é um livro que tenta explicar, a partir do entendimento da diversão em si, o que torna alguns jogos divertidos enquanto outros são chatos. Ele tenta decifrar o que torna as coisas divertidas. E praticamente qualquer coisa pode ser divertida, não só jogos. Acontece que o objetivo final dos jogos é quase que exclusivamente a diversão. As pessoas jogam e brincam para se divertir. Bons jogos podem fazer mais do que isso, como exercitar habilidades sociais e ensinar novas idéias. Mas na maioria das vezes o que você quer fazer quando procura um jogo é simplesmente se divertir.

Para outros tipos de programas de computador a diversão não é o objetivo principal. Algumas vezes nem de longe. Mas diversão pode ser uma característica bastante atraente em muitas outras aplicações. Jogos precisam ser envolventes e divertidos se quiserem sobreviver. Se quiserem ser jogados. Se quiserem ser usados. É neste sentido que todo programador deveria escrever jogos. Não é porque uma aplicação não é vista prioritariamente como um jogo que ela não deva ser divertida, que seus autores não precisam se preocupar em entreter quem vai usá-la.

Vamos tomar o Stackoverflow como exemplo. Ele é um site de perguntas e respostas sobre problemas de programação. À primeira vista isso não se parece nada com um jogo, mas o sistema foi propositalmente concebido como um. Alguns aspectos foram inspirados especificamente no sistema de façanhas do Xbox 360 (ou como quer que os jogadores de Xbox traduzam “achievement”). Os pontos de reputação que você recebe como prêmio pela participação no site também são um aspecto que dá um ar de jogo à experiência e estimula uma competição saudável. Por causa dessa recompensa (que, por sinal, não passa de um direito de se gabar) mais perguntas são respondidas e com melhor qualidade. O aspecto de jogo ajuda o sistema, e a comunidade como um todo, a atingir a sua meta.

Aplicações divertidas são usadas com mais freqüência e dedicação. No fim das contas o trabalho do usuário acaba saindo melhor se ele se divertir no processo. Como diria a Kathy Sierra, ajudar seus usuários a arrasar deveria ser sempre seu objetivo, não?

Então quando estiver projetando alguma aplicação, talvez faça sentido pensar em como tornar a experiência mais divertida. Talvez você possa até incorporar recursos normalmente encontrados em jogos de computador para ajudar seus usuários a tirarem mais proveito da experiência. Talvez seja você possa pensar no sistema todo como um jogo.

Sites de rede social são plataformas, não aplicações

Eu lembro quando as primeiras redes sociais começaram a se popularizar por estas bandas. E por popularizar, é óbvio que eu quero dizer que começaram a ser usadas pelos primeiros geeks. No início éramos só nós que usávamos esse tipo de coisa. Depois começaram a surgir o que vou chamar de “geeks de segundo nível”, o pessoal que acompanha tecnologia mas que inicialmente estava cético quanto à utilidade dessas coisas. Esses acabaram se convencendo depois que todos os outros geeks estavam usando. Depois disso foi só aproveitar a inércia: começaram a aparecer pessoas interessadas mais nas possibilidades de interação humana que na tecnologia, atraídas pelo que seus amigos geeks estavam conseguindo dessa nova mídia e pela facilidade de operá-la. Foi neste ponto que começaram a chegar as meninas de treze anos, os perfis falsos, os pedintes (me add! me add!) e aí…

Aí os usuários originais começaram a debandar. Aquela idéia do início já não parecia tão boa. Na verdade parecia uma péssima idéia. A relação sinal-ruído desequilibrou demais para o lado do ruído: mais um caso internético típico da maldição da popularidade.

Mas se a idéia era tão ruim, como conseguiu atrair aqueles geeks no início?

Acontece que a idéia não era ruim. Geeks são muito bons para detectar boas plataformas e foi isso que eles fizeram. Eles começaram a adotar aquela idéia por causa do seu potencial. Não pelo que ela oferecia na época, mas pelo que ela poderia vir a oferecer. Quando as redes sociais falharam em aproveitar esse potencial, eles as abandonaram.

O grande erro dos sites de rede social foi não perceber que o que tinham em mãos era uma plataforma para aplicações, não uma aplicação final. Felizmente isto vem mudando nos últimos anos, com a disponibilização de interfaces de programação para que terceiros hospedem aplicações sobre estes sites e o futuro pode voltar a parecer promissor novamente.

Hoje a maioria das aplicações no Orkut, por exemplo, são basicamente inúteis. Temos desde aplicativos que servem simplesmente para permitir que você use o grafo social para encher o saco de seus amigos até os sites com conteúdo externo que não usam praticamente nada do grafo social mas resolveram subir nesse trem por causa da audiência. Sem contar os mini-aplicativos publicitários sem muita criatividade. Olhando por este lado, o futuro não parece muito alegre. Mas o valor de uma plataforma não está nas aplicações que já foram feitas, mas nas que podem ser feitas.

E o que pode ser feito com essas redes sociais? Ninguém sabe ainda. Se alguém soubesse, já teria sido feito. A questão é que você não pode dizer que esse negócio de rede social não vai pra lugar nenhum só porque ninguém fez nada de interessante ainda. Isso não impede que alguém faça algo no futuro. Se em 1992 você dissesse que a web não iria para lugar nenhum, sua opinião pareceria bastante plausível, mas por volta do ano 2000 teria sido provado o contrário. É bem verdade que as redes sociais podem realmente nunca nos trazer nada de útil, mas isso não pode ser afirmado com base no passado.

A própria web não era muito atrativa na década de 90, mas os geeks viram seu potencial e a transformaram em uma mídia riquíssima. No início não havia aplicações web muito interessantes, mas havia potencial. Se vamos usar as aplicações sobre redes sociais somente para jogar frutas virtuais em nossos amigos ou arranjar algo de útil para fazer é uma decisão que está primeiramente em nossas mãos, desenvolvedores web e geeks em geral. Se conseguirmos construir algo que ajude as pessoas, elas virão.

Quem está preocupado com SEO já está perdido

Como assim? Você me pergunta. Você não deveria estar preocupado com a classificação do seu site em engenhos de busca? Mas 96% dos visitantes chegam aos sites através deles!

Tudo bem, deixe-me explicar. Para ficar mais fácil, vamos voltar às bases.

SEO é um acrônimo para Search Engine Optimization que numa tradução bem pé-duro quer dizer Otimização de Engenho de Busca. Aqui já dá pra ver a inconsistência: quem faz otimização dos engenhos de busca são os donos dos engenhos de busca, ora bolas, não os responsáveis pelos sites indexados. Você simplesmente não consegue otimizar algo que você não controla.

Digamos que você escreveu uma rotina para ordenar os valores de uma lista. Como você faz para otimizá-la? Você olha o que pode modificar e reescreve algumas partes de modo a executar mais rápido, consumir menos memória ou algo do tipo, claro. O que definitivamente não conta como otimização da sua rotina é exigir que a entrada sempre venha ordenada de modo que ela não precise fazer nenhum trabalho.

Entretanto, o que se denomina de SEO hoje em dia é basicamente isso, modificar a web para tornar mais fácil para os engenhos de busca acharem o conteúdo. O termo evoluiu para significar Otimização para Engenho de Busca. Muitas vezes é usado como sinônimo para o ato de massagear sites ou páginas de modo a obter uma classificação favorável em relação a alguns termos específicos. Algumas vezes isso inclui até esquemas obscuros de troca de links. O objetivo disso é, no final de tudo, aparecer entre os primeiros resultados quando alguém procurar por algumas palavras relacionadas a seu conteúdo. Chega-se a bolar todo tipo de coisa para conseguir isso, mas a solução definitiva é mais simples do que parece.

Para garantir que sua página vai figurar entre os resultados mais relevantes para um termo de busca basta ter o melhor conteúdo para aquele termo.

Se você tem um site de resenhas de produtos que tem inquestionavelmente a melhor resenha do mundo referente a um produto em particular e alguém procura pelo nome do produto e seu site não aparece em primeiro ou segundo colocado (vamos admitir que o site do fabricante do produto possa ser o primeiro), a falha é dos engenhos de busca, não sua. É o trabalho deles achar o melhor conteúdo. O seu trabalho é ter o melhor conteúdo. Se eles não estão achando o seu conteúdo, simplesmente não estão trabalhando direito.

Não importa como vão fazer para encontrar o melhor conteúdo, eles têm que encontrar. É o que eles se propõem a fazer. É a razão deles existirem. Não importa se eles vão levar em consideração a quantidade de links que cada página recebe em toda a web ou se vão contratar críticos literários para ler e classificar todas as páginas do mundo.

O pessoal do engenho de busca não pode reclamar que você não colocou o nome do produto na URL ou que não incluiu algum tipo de meta-dado para facilitar a indexação. Nada disso importa quando o seu conteúdo é o melhor. Claro que você deve tomar cuidado para tornar o conteúdo fácil de encontrar, garantir que ele vai ser acessível para visitantes usando programas de leitura de tela e certificar-se que o título da página faz sentido. Mas nada disso é SEO, esse tipo de coisa é só Introdução à Web.

SEO no sentido literal só pode ser realizado pelos donos dos engenhos de busca. O melhor meio de fazer SEO como o termo é comumente usado é simplesmente gerar o melhor conteúdo em toda a web. Neste sentido, você não deve perder seu tempo com SEO justamente porque SEO é o que você deveria estar fazendo o tempo todo desde o início.

Código que fala por si só

Uma justificativa (ou desculpa, dependendo de que lado se olhe) bastante comum de equipes que desenham diagramas para qualquer pequeno aspecto de suas aplicações é que eles servem para ajudar a ler o código. Tornam aquela bagunça emaranhada que é o código em algo mais dócil. Traduzem a verborragia computacional em algo mais compreensível para um mero humano.

O objetivo aqui é certamente louvável. Quem não quer uma aplicação fácil de entender? O problema é que este tipo de discurso parte de uma premissa bastante questionável: a de que código é inerentemente difícil de se ler e entender. Estou usando aqui o exemplo dos diagramas, mas o mesmo problema acontece quando se tenta escrever comentários para cada linha de código. Muda o paciente, mas a doença é a mesma.

Digamos que você esteja escrevendo um livro. Você pensou em um bom tema para a estória, delineou vários personagens e conseguiu imaginar até um cenário interessante para o pano de fundo. Mas seus dotes literários não estão muito apurados e o texto começa a ficar meio emaranhado. Você não sabe onde terminar uma cena e começar outra, não sabe onde encaixar os diálogos e qualquer um que começa a ler se perde depois do quarto parágrafo. Apesar disso você tem uma boa estória para contar. O que você faz? Enche o livro de figuras coloridas? Faz um filme para ser distribuído em conjunto?

Claro que não. Você reestrutura a história e reescreve o livro se for preciso. Você não faz uma representação paralela dele em outra mídia, você torna a mídia original mais acessível. Se você não conseguir fazer isso, é melhor procurar outra coisa para fazer. Talvez você possa aprender a escrever melhor se estudar um bocado. Ou talvez você não tenha talento mesmo.

Para o código a solução é a mesma. O texto do programa deve falar por si só, não se deve assumir que há alguma outra representação alternativa para torná-lo mais claro. Se o relacionamento entre as várias partes do código está obscuro, ele deve ser reestruturado de forma a ficar mais claro. Se o nível de detalhamento das rotinas chamadas dentro de um trecho está muito perto do metal bruto, agrupe alguns blocos em rotinas separadas ou crie novo objetos. Faça o que fizer sentido, mas não deixe o código ficar sujo. Assim como todo bom escritor pensa o tempo todo em seus leitores, pense o tempo todo em quem vai ler seu código.

Isso não quer dizer que nunca devamos usar uma representação gráfica ou comentários para explicar código. Voltando à analogia dos livros, ilustrações são coisas legais de se encontrar, só não devem ser partes essenciais do conteúdo. Talvez fique mais fácil entender o que o autor imaginou com elas, mas qualquer bom livro que tenha as ilustrações removidas continuará tão bom quanto antes.

Você não é uma vaca leiteira

…então, por favor, não trabalhe como se fosse.

Vale a pena prestar um pouco de atenção nos aspectos ergonômicos do seu ambiente de trabalho. Coisas como monitores bonitos, uma quantidade absurda de portas USB e uma biblioteca de música praticamente inesgotável são importantes para qualquer programador. Mas algumas coisas mais simples são igualmente importantes, como a altura da sua cadeira, a posição do seu teclado e, muito surpreendentemente, o bom e velho espaço livre.

Espaço livre não parece estar muito na moda ultimamente. É raro encontrar alguém que dá alguma importância para isso. Afinal de contas, o trabalho de um programador (e de qualquer trabalhador do conhecimento, para este efeito) acontece dentro da cabeça. Não é necessário muito espaço para abrigar a cabeça de uma pessoa, mesmo se levarmos em consideração que ela é inseparável dessa massa inútil e disforme que chamamos de corpo. Talvez seja por isso que tantas empresas dão o mesmo espaço de trabalho para os programadores que uma fazenda intensiva daria para uma vaca leiteira. Uns só precisam das tetas, outros só da cabeça. Quanto mais programadores couberem no mesmo espaço, mais software será produzido por metro quadrado. Simples otimização de chão de fábrica, certo?

dairy_cowders

Sim, é fato que sua cabeça (ainda) não pode viver separada do seu corpo. Portanto, mesmo que você não ligue para seu corpo em si, é melhor cuidar dele se quiser continuar usando sua inteligência por muito tempo. Esse cuidado passa por aspectos bastante óbvios (e penosos) como praticar exercícios regularmente e manter uma dieta equilibrada. Pode não ser muito fácil cuidar disso, mas os aspectos ergonômicos do ambiente de trabalho são muito mais controláveis. Mesmo assim costumam ser negligenciados.

Este é meu escritório de casa atualmente (bom, pelo menos a parte sobre a qual quero falar hoje):

my_office

A mesa é em geral o espaço onde você vai passar a maior parte do tempo. Não importa se você tem acesso a uma mesa de sinuca e a três video-games diferentes para jogar Rock Band com seus colegas durante o horário de trabalho. Se sua mesa for desconfortável, você não vai produzir muito. Pensando bem, se lhe derem uma mesa inadequada, é bem mais provável que você passe mais tempo jogando Rock Band do que programando.

A primeira coisa que você vai querer garantir para sua estação de trabalho é uma cadeira confortável. Ela precisa ter ao menos encosto reclinável, ajuste de altura e apoio para os braços. E estofamento macio, claro. Você não vai querer ficar sentado o dia todo numa pilha gigantesca de algodão. Tampouco em um banco de praça. Ache um meio termo que pareça bom para você e use-o. Não é preciso gastar dois mil reais numa cadeira para ter todos estes recursos, mas também não é um valor assim tão absurdo se considerarmos a durabilidade do equipamento e o custo do programador para a empresa.

O próximo item da lista é uma mesa espaçosa. Segundo o Peopleware, um estudo encomendado pela IBM há muitas luas atrás descobriu que a superfície mínima que uma pessoa precisa para ser produtiva é de aproximadamente 2,5m². Minha mesa deve ter aproximadamente 1,75. Ainda estou abaixo da meta, mas com certeza é mais do que os dois caras da foto têm e pelo menos é o suficiente para caber com sobra meus dois monitores.

O que nos leva ao próximo item indispensável a qualquer pessoa que desenvolva software: muito espaço de tela. Com dois monitores de 1280×1024 você obtém uma área útil de 2560×1024 pixels, o que é suficiente para abrigar ao menos um editor com seu código e o programa rodando ao mesmo tempo. Se apertar um pouco, cabe até uma janela para monitorar os testes automáticos. Mas você pode achar útil ter algum material de referência aberto para consultar rapidamente e talvez precise de um terceiro monitor para isso. Como você está lendo isso aqui, provavelmente já tem um dos monitores. Um extra deve estar abaixo dos 600 paus hoje em dia e a maioria das placas de vídeo modernas já aceita duas saídas. É produtividade de graça se você jogar na conta o tempo (e a paciência) que se perde chaveando janelas numa tela só.

Você também vai querer ter seus vários monitores posicionados corretamente. Uma distância entre 40 e 75cm entre seus olhos e a tela é o suficiente. É preciso tomar cuidado para posicioná-los na altura correta também (vale usar livros velhos quando o monitor não tem regulagem de altura). Você não vai querer ficar com a cabeça inclinada nem para cima nem para baixo o dia todo. As dores no pescoço podem ser bastante irritantes depois de um tempo.

Além da altura dos monitores, você também precisa regular a altura da cadeira e da mesa para manter suas pernas e braços em ângulos mais ou menos retos a maior parte do tempo. Isso vai aliviar bastante a coluna e pode garantir boas noites de sono. Simplesmente procure um pouco na web sobre ergonomia no trabalho que você vai achar várias dicas, há bastante material por aí.

Quando não estiver trabalhando, não esqueça de comer seus vegetais e fazer seus exercícios e lembre-se de que se exercitar durante o trabalho também é importante. Você não precisa levantar para correr meia-maratona no horário do almoço. Alguns alongamentos uma ou duas vezes ao dia já são suficientes. Você também pode querer manter por perto algumas daquelas bolinhas terapêuticas, daquelas vendidas em lojas de animais. Elas são ótimas para exercitar a musculatura do punho que tanto castigamos ao digitar o dia inteiro e ainda servem para massagear a tensão acumulada.

Um último toque que você talvez não encontre em todo site sobre ergonomia fica bem no canto direito na minha mesa. Uma foto de pessoas que você gosta (de uma viagem com a esposa, como esta minha) é importante para lhe lembrar que por mais que seu código pareça perfeito e sem falhas (e, acredite, ele nunca é) e que você passe o dia conversando em linguagens estranhas com essa máquina maluca de duas cabeças, no fim das contas você é apenas humano e precisa de outras pessoas assim como qualquer outro ser humano.

Ninguém liga para sua relação teste-para-código

Tenho visto muita gente recentemente se gabando da relação teste-para-código de seus projetos. As pessoas medem a quantidade de linhas de código do sistema em si e a quantidade de linhas de código dos testes automáticos e publicam a relação de uma para a outra, como se isso quisesse dizer algo sobre a qualidade do sistema. Permita-me ser bem claro:

Ninguém dá a mínima para a sua relação teste-para-código.

Nem para sua taxa de cobertura de testes, se é que isso interessa.

A menos que a relação seja zero-para-um, não há absolutamente nada de informativo neste número. A partir do momento em que você está escrevendo algum teste, fazer este número crescer não garante melhoria nenhuma na qualidade do sistema. Talvez você esteja escrevendo testes inúteis para verificar se sua linguagem de programação consegue atribuir um valor a uma variável e recuperá-lo de volta. Talvez você esteja repetindo os mesmos testes o tempo todo. Testar é bom, mas alguns testes são melhores do que outros e este número não é calculado sobre a qualidade dos testes, só a quantidade deles. Não há nenhuma conclusão útil que eu possa tirar do seu número sem dar uma olhada no seu código.

Cobertura de testes é outra métrica bem vazia. Claro que você deve tentar se aproximar tanto quanto possível de 100%, mas a verdade é que chegar a níveis de cobertura acima de 90% não é tão difícil assim. Considere, por exemplo, este trecho de código adaptado do Code Complete do Steve McConnell:

    totalWithholdings = 0;

    for ( id = 0; id < numEmployees; id++) {
        if (m_employee[id].governmentRetirementWithheld < MAX_GOVT_RETIREMENT) {
            governmentRetirement = ComputeGovernmentRetirement(m_employee[id]);
        }

        companyRetirement = 0;

        if (m_employee[id].WantsRetirement &&
            EligibleForRetirement(m_employee[id])) {
            companyRetirement = GetRetirement(m_employee[id]);
        }

        grossPay = ComputeGrossPay(m_employee[id]);

        personalRetirement = 0;
        if (EligibibleForPersonalRetirement(m_employee[id])) {
            personalRetirement = PersonalRetirementContribution(m_employee[id],
                companyRetirement, grossPay);
        }

        withholding = ComputeWithholding(m_employee[id]);
        netPay = grossPay - withholding - companyRetirement -
            governmentRetirement - personalRetirement;

        PayEmployee(m_employee[id], netPay);

        totalWithholdings = totalWithholdings + withholding;
        totalGovernmentRetirement = totalGovernmentRetirement +
            governmentRetirement;
        totalRetirement = totalRetirement + companyRetirement;
    }

    SavePayRecords(totalWithholdings, totalGovernmentRetirement,
        totalRetirement);

É possível obter 100% de cobertura para este trecho completo com apenas um teste: você só precisa garantir que há ao menos um funcionário (para que o loop seja executado) e que as três cláusulas condicionais avaliem para verdadeiro. Obviamente um único teste não é o suficiente para testar todas as nuances deste código e, de fato, McConnel mostra no livro que são necessários pelo menos dezessete testes diferentes. Mesmo assim se tivéssemos escrito aquele único caso de teste, enxergaríamos cobertura total.

Parece que virou moda ultimamente supervalorizar os testes e divulgar estas métricas vazias. No fim das contas elas funcionam como qualquer métrica para software, só dão uma visão bem abstrata do sistema e podem muitas vezes serem enganosas. Não há substituto para uma boa leitura do código.

Tendo dito isso tudo, eu definitivamente não recomendo tentar desenvolver software sem escrever testes automáticos. Já é difícil desenvolver software usando testes, mas é ainda pior sem eles. Só porque você sabe que não é possível provar ausência de defeitos através de testes, não quer dizer que não deva usá-los. Então, por favor, continue escrevendo-os (ou passe a escrever se você não escreve ainda). Só não aja como se eles fossem a última salvação da humanidade. Eles são só a primeira.

Resenha: A Cauda Longa

Há quinze anos atrás, se eu quisesse escutar algum programa de notícias ou entrevistas poderia usar um rádio para escolher dentre algumas dezenas de opções no máximo. A maioria delas seria inevitavelmente sobre política, impostos ou gente famosa. Esses assuntos interessam a basicamente todo mundo e os limites físicos dos canais de distribuição da época forçavam os produtores a apostar apenas nos programas que pudessem atrair a maior quantidade possível de ouvintes — e, por conseqüência, anunciantes. Há somente tantas freqüências FM disponíveis e o dia só tem 24 horas. Se eu quisesse escutar um programa sobre interesses um pouco mais específicos (como carpintaria ou eletrônica, por exemplo), teria que me contentar com algum horário de madrugada ou desistir da busca. O famigerado “horário nobre” estava sempre ocupado com os mesmos assuntos que interessavam a todo mundo.

Ao avançar para o século XXI nos deparamos com um cenário completamente diferente. Agora já não é mais tão difícil encontrar um podcast sobre qualquer assunto na face da terra — incluindo carpintaria e eletrônica. Melhor ainda: posso armazenar meus programas favoritos em um tocador portátil e escutar na hora que quiser. Posso até mesmo descobrir um novo programa hoje e baixar todo o conteúdo arquivado dos últimos dois anos. Enfim, posso ter uma rádio regulada especificamente para meus interesses fornecendo conteúdo num fluxo contínuo e sem fim. Isso é bom tanto para os consumidores, que têm acesso a conteúdo interessante de maneira personalizada, como para os produtores, que não precisam abordar sempre os mesmos assuntos repetidos. Eles podem ser tão especializados quanto quiserem que vão encontrar pelo menos uma dezena de ouvintes interessados em um assunto de nicho.

No fundo, A Cauda Longa de Chris Anderson é um livro sobre prateleiras e como elas evoluíram para tornarem-se virtualmente infinitas. Quando se tem limites físicos para a exposição dos produtos — como nas prateleiras de um super-mercado ou no espectro de tempo de uma rádio FM, faz sentido apostar apenas nas opções mais populares, nos campões de vendas. Você precisa garantir que o espaço será bem aproveitado e não tem muita folga para arriscar. Esse modelo de distribuição acaba criando um círculo vicioso: as pessoas só consomem o que está disponível e os distribuidores só disponibilizam o que as pessoas consomem.

Mas se as prateleiras fossem infinitas, poderíamos exibir todos os produtos e deixar o público escolher. Obviamente ainda haveriam grandes campeões de vendas, mas com uma diferença: eles seriam medidos, não induzidos. Seriam escolhidos pelo público, não por uma aposta dos distribuidores.

Acontece que é exatamente isto que vem acontecendo nas últimas décadas. As lojas online e os meios de distribuição modernos estão tornando as prateleiras virtualmente infinitas. Não há quantidade máxima de livros que cabem numa livraria na web. Não há músicas demais que não caibam na loja do iTunes. Não há DVDs demais para a Netflix. Os distribuidores modernos podem trabalhar com o todo o espectro de produtos, ao invés de serem obrigados se concentrarem somente nos grandes sucessos. Como nos mercados de cauda longa o custo de distribuir um campeão de bilheteria é o mesmo de um produto de nicho, não há necessidade de tentar adivinhar quais serão os grandes sucessos. Há tantas ou mais oportunidades nos produtos de nicho — milhares de produtos que individualmente atraem algumas dezenas de pessoas — quanto nos grandes sucessos — algumas dezenas de produtos que sozinhos arrastam multidões.

Anderson identifica três forças principais que possibilitam esses mercados de cauda longa. A primeira é a democratização das ferramentas de produção, o que torna qualquer pessoa com um computador um produtor de conteúdo em potencial. A segunda é a democratização da distribuição, que permite aos produtores oferecerem seu conteúdo a um público realmente interessado nele. A terceira força são os filtros de distribuição. Eles ajudam a conectar os produtores ao público interessado no seu trabalho e vão desde os recursos de “itens relacionados” em sites como Amazon, Submarino e Youtube até a boa e velha propaganda boca-a-boca. Sem eles, toda essa oferta de produtos de nicho não passaria de uma grande fonte de ruído e ninguém acharia o que procura. Afinal de contas, meus interesses de nicho são diferentes dos seus interesses de nicho. Por isso são chamados de interesses de nicho, ora bolas!

A diferença entre a propaganda boca-a-boca de hoje e a de quinze anos atrás é o fato da Internet ter colocado um megafone na mão de cada pessoa. Agora é muito mais fácil indicar conteúdo e produtos a pessoas com interesses parecidos. Se você não viu o vídeo do “cara que não tá legal não”, por exemplo, você não é o público-alvo dele (ou então talvez você seja, e acabou de descobrí-lo). E não é preciso nem ter um blog para ter esse tipo de poder: todo mundo está indicando produtos para pessoas com interesses similares quando compra um produto em qualquer loja online.

Há uma citação de David Foster Wallace no capítulo sobre televisão e distribuição de vídeo que resume muito bem o espírito da cauda longa:

A televisão é como é simplesmente porque as pessoas tendem a ser extremamente semelhantes em seus interesses vulgares, lúbricos e parvos, e muitíssimo diferentes em seus interesses refinados, estéticos e nobres.

As coisas que são medianamente interessantes para você também o são para muitas pessoas. É disso que são feitos os grandes sucessos: fórmulas comuns que atraem muita gente mas não com tanta força. Por isso novelas fazem sucesso. Por isso todas novelas parecem ser iguais. A diferença nas coisas altamente interessantes é só serem altamente interessantes para poucas pessoas. Os assuntos mais atraentes para uma pessoa são verdadeiras chatices para a próxima. Os assuntos pelos quais somos realmente apaixonados atraem pouca gente, mas com muita força. É disso que é feita a cauda longa.