Mergulhando no Caos

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.

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.

…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?

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):

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.

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.

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.

Gerentes de projeto precisam ter várias habilidades para realizar um trabalho satisfatório. Elas vão desde boa capacidade de comunicação e habilidades de negociação até desenvoltura com estimativas e prazos em constante mutação. Mas a habilidade de sair da porcaria do caminho certamente é uma das mais importantes.

Considere-se com sorte se você nunca teve um gerente que pedia relatórios de status diários (ou até com freqüência maior) ou que parecesse ter uma queda especial por reuniões. Principalmente por aquelas bem longas e tediosas. Todo mundo já teve ou ainda vai ter um gerente como esse. E eles fazem parecer que gerentes só servem para encher o saco e lhe atrapalhar de terminar o trabalho de verdade que você faz durante o tempo entre uma reunião e outra.

Mas o bom gerente sabe como sair do caminho. Ele consegue ajudar sem atrapalhar, sem perguntar o tempo todo o que a equipe precisa. Ele simplesmente sabe o que eles precisam, mesmo que eles mesmos não saibam.

Há milhões de coisinhas que não são programação que são necessárias para fazer um produto de software de sucesso. Coisas chatas como reuniões com a diretoria, contabilidade, servidores de produção, manutenção do ar-condicionado, servidores de produção, publicidade, infra-estrutura de rede decente, servidores de produção, impostos e servidores de produção. Bons gerentes fazem parecer que estas coisas não precisam ser resolvidas com cuidado, fazem parecer que elas estão lá e simplesmente funcionam.

Para colocar em termos que um programador vai entender, bons gerentes são capazes de criar uma camada de abstração pra o desenvolvedor. Eles conseguem fazer com que o trabalho pareça constituir-se somente de cuspir código o dia inteiro. Eles fazem os programadores se sentirem bem por poderem fazer o tempo todo aquilo que gostam de fazer. Eles respondem os relatórios de status da equipe para os gerentes deles com um mínimo de distúrbio para os programadores. Eles vão para as reuniões que parecem que nunca vão acabar para que o resto da equipe não precise ir. Eles não se escondem atrás de suas escrivaninhas funcionando como um roteador de tarefas delegando tudo que precisa ser feito.

Esta habilidade de sair do caminho torna os bons gerentes virtualmente invisíveis para sua equipe. Os melhores são tão bons nisso que parece que não estão fazendo nada, que são completos vagabundos. Quando eles estão fazendo um bom trabalho, o pensamento dos programadores de sua equipe deve passar várias vezes pela questão “o que este sanguessuga fica fazendo o dia todo enquanto eu escrevo código aqui para fazer essa porcaria funcionar?”. A sina deles é parecer cada vez mais inúteis à medida que se tornam mais úteis.

Não costumo fazer traduções porque em geral não gosto delas: a maioria parece um arremedo do original e quando prestam você está no máximo lendo o texto do tradutor e não o do autor. Mas o texto “The other half of ‘Artists ship’” do Paul Graham é tão bom que não consegui me segurar. Tecnicamente o que vem aí abaixo é mais uma versão do que uma tradução (o original, por exemplo, não tinha nenhuma referência nem tantas ênfases em itálico): uma versão minha para o que o autor disse que pode inclusive não ter nada a ver com o que ele quis dizer. Então o que você vai ler aqui não é exatamente o que o Graham escreveu originalmente. Portanto, se você se sente à vontade para ler textos em inglês, vá em frente, clique no link acima e esqueça a minha versão. Caso contrário, corra para aprender inglês — todo programador que se preza sabe ao menos ler inglês — e contente-se com minha versão ridiculamente patética neste meio-tempo.

Uma das muitas diferenças entre as empresas grandes e as pequenas é que as grandes tendem a desenvolver procedimentos de auto-proteção contra erros. Uma empresa que está iniciando anda mais ou menos como um bebê: esbarra nas coisas e cai o tempo todo. Empresas grandes são mais ponderadas.

O acúmulo gradual de verificações em uma organização é um tipo de aprendizado baseado nos desastres que aconteceram com ela mesma ou com organizações parecidas. Depois de assinar um contrato com um fornecedor que declara falência e não entrega o que deveria, por exemplo, uma empresa pode passar a exigir que todos os fornecedores provem sua solidez antes de fazerem uma oferta.

À medida que as empresas crescem elas invariavelmente desenvolvem mais dessas verificações, seja em resposta a desastres que sofreram ou, provavelmente com mais freqüência, por contratar pessoal oriundo de empresas ainda maiores que trazem consigo seus dispositivos de proteção contra tipos de desastres novos.

É natural que as organizações aprendam com seus erros. O problema é que quem propõe novas verificações quase nunca considera que a verificação em si tem um custo.

Toda verificação tem um custo. Considere, por exemplo, o caso de exigir que os fornecedores comprovem solidez. Parece mera prudência, não? Mas na realidade pode ter custos significativos. Existe obviamente o custo direto de tempo de gente dos dois lados para fornecer e verificar provas de solidez. Mas os custos que realmente importam são os que nunca chegamos a conhecer. Como, por exemplo, a empresa que seria a melhor fornecedora, mas não se candidata porque não pode se dar ao luxo de despender o esforço necessário para ser verificada. Ou a empresa que seria a melhor fornecedora, mas fica logo abaixo do limite considerado para a solidez — que obviamente foi puxado para cima, já que não há nenhum custo aparente para aumentá-lo.

Sempre que alguém em uma organização propusesse uma nova verificação, deveria ter que explicar não só o benefício mas também o custo. Não importa quanto o trabalho de análise fosse ruim, esta meta-verificação iria ao menos lembrar a todos que deve haver um custo e fazê-los procurar por ele.

Se as empresas começassem a fazer isso, encontrariam algumas surpresas. Joel Spolsky palestrou recentemente na Y Combinator sobre venda de software para clientes corporativos. Ele disse que na maioria das empresas software que custe até aproximadamente $1.000 dólares pode ser adquirido pelos gerentes sem necessidade de aprovações adicionais. Acima desse limite as aquisições de software geralmente precisam ser aprovadas por um comitê. Mas bajular esse processo é tão custoso para os fornecedores de software que não faz sentido cobrar abaixo de $50.000 dólares. O que significa que se alguém produz algum produto pelo qual normalmente cobraria $5000, acaba sendo obrigado a vender por $50.000.

O propósito do comitê presumivelmente é garantir que a empresa não desperdice dinheiro. Apesar disso, o resultado é que eles acabam gastando dez vezes mais.

Verificações de aquisição vão sempre ser caras, porque quanto mais difícil for fazer você comprar algo, mais o preço vai aumentar. E não necessariamente linearmente. Se for suficientemente difícil lhe vender algo, quem for o melhor em fazer as coisas simplesmente não vai querer perder tempo. Os únicos que vão vender para você são as empresas especializadas em vender para você. Quando chega a este ponto você já está afundado em um nível inteiramente novo de ineficiência. Os mecanismos de mercado normais não vão lhe proteger, porque os bons fornecedores nem estão mais no mercado.

Essas coisas acontecem o tempo todo nas maiores de todas as organizações: governos. Mas verificações estabelecidas por governos podem causar problemas bem piores do que superfaturamento. Verificações estabelecidas por governos podem aleijar toda a economia de um país. Até mais ou menos 1400, a China era mais rica e tecnologicamente mais avançada que a Europa. Uma das razões para a Europa ter conseguido ultrapassar foi que o governo chinês restringiu viagens de comércio longas. Com isso só sobraram os europeus para explorar e eventualmente dominar o resto do mundo. Incluindo a China.

Mais recentemente, a lei Sarbanes-Oxley praticamente destruiu o mercado americano de ofertas públicas. Essa não foi a intenção dos legisladores que a escreveram, eles simplesmente queriam acrescentar algumas verificações sobre empresas públicas. Mas esqueceram de considerar o custo. Esqueceram que empresas na iminência da abertura geralmente estão com os cintos bem apertados, e que o peso de algumas verificações a mais pode ser fácil para a General Electric enfrentar mas são o que basta para evitar que empresas mais jovens sequer considerem uma oferta pública inicial.

Quando você começa a pensar no custo das verificações, começa a fazer outras perguntas interessantes. O custo está aumentando ou diminuindo? É mais alto em algumas áreas do que em outras? Onde ele cresce de forma descontínua? Se grandes organizações começassem a fazer perguntas desse tipo, descobririam algumas coisas bem assustadoras.

Eu acredito que o custo das verificações está na verdade aumentando. O motivo é que o software ocupa uma posição importante nas empresas, e que as pessoas que escrevem software são atingidas de um modo peculiar pelas verificações.

Programadores são um tipo de trabalhador diferente na medida em que os melhores preferem trabalhar duro. Este não parece ser o caso na maior parte das ocupações. Quando trabalhei com fast food, nós não preferíamos os tempos atarefados. E quando aparava gramados, eu definitivamente não preferia quando a grama estava alta depois de uma semana de chuva.

Programadores, no entanto, gostam quando escrevem mais código. Ou, mais precisamente, quando publicam mais código. Programadores gostam de fazer a diferença. Os bons, pelo menos.

Para os bons programadores, um dos melhores aspectos de trabalhar para uma empresa pequena é que há poucas verificações para publicação. Em empresas iniciantes, não há nenhuma verificação externa. Se você tiver uma idéia para um recurso novo pela manhã, pode escrevê-lo e enviar para os servidores de produção antes do almoço. E quando pode fazer isso, você acaba tendo mais idéias.

Em empresas grandes, o software precisa atravessar várias aprovações antes de poder ser liberado. E o custo de fazer isso pode ser enorme. Eu estava conversando recentemente com um grupo de três programadores cuja empresa havia sido adquirida há alguns anos por uma empresa grande. Quando eram independentes, eles podiam liberar modificações instantaneamente. Agora, eles disseram, o mais rápido que poderiam disponibilizar o código nos servidores de produção é em duas semanas.

Isto não os tornou simplesmente menos produtivos. Fez com que odiassem trabalhar para o comprador.

Aqui vai uma evidência do quanto os programadores gostam de poder trabalhar duro: esses caras pagariam para poder publicar código de imediato do jeito que estavam acostumados. Perguntei se eles trocariam 10% do preço de aquisição pela habilidade de publicar código de imediato e todos os três instantaneamente disseram que sim. Então perguntei qual seria a percentagem máxima do preço de aquisição que trocariam. Eles disseram que preferiam não pensar nisso, pois não queriam descobrir o quão alto iriam, mas tive a impressão que seria mais ou menos a metade.

Esse pessoal teria sacrificado centenas de milhares de dólares — talvez milhões — só para poder disponibilizar mais software para os usuários. E sabe de uma coisa? Seria perfeitamente seguro permitir que o fizessem. Na verdade, o comprador estaria bem melhor; não somente esses caras não quebrariam nada, eles teriam conseguido fazer muito mais. No fim das contas o comprador está tendo performance mais baixa a custo mais alto. Do mesmo jeito que o comitê que aprova aquisições de software.

Assim como o maior perigo de ser difícil de ser convencido a comprar não é pagar superfaturado, mas o fato dos melhores fornecedores nem mesmo quererem vender para você; o maior perigo de aplicar verificações demais a seus programadores não é torná-los improdutivos, mas fazer que os bons programadores nem mesmo queiram trabalhar para você.

A famosa máxima de Steve Jobs “artistas publicam” é aplicável nos dois sentidos. Artistas não são somente capazes de publicar. Eles insistem nisso. Assim, se você não deixar as pessoas publicarem, não terá nenhum artista.

Você já notou como tornar seu código bonito e elegante não é tão difícil uma vez que você sabe exatamente o que ele tem que fazer? Quando o problema está bem definido, não há muita dificuldade em tornar a solução mais elegante. Veja o problema da ordenação, por exemplo. Ao longo dos anos surgiram várias soluções justamente porque o problema é suficientemente simples e bem compreendido. Mas se você quiser se aventurar no reino das aplicações-corporativas-de-intranet-nossas-de-cada-dia, é melhor se preparar para ver um bocado de código feio.

Horrível, na verdade.

Esse tipo de código não é feio porque quem o escreve não saiba programar direito. Os programadores que fazem essas aplicações não podem deixar o código bonito porque na maioria dos casos eles não sabem muito bem o que construir. Para escrever código bonito, eles precisam primeiro saber o que o código deve fazer. Claro que também precisam estudar bastante e dominar as técnicas de programação mais recentes, mas não vão ter a mínima chance se não souberem o que estão tentando construir.

Entender bem os requisitos e fazer o que o cliente precisa é insanamente mais importante do que escrever código bonito (não que a beleza do código também não seja importante). É o trabalho que realmente importa em desenvolvimento de software, certo?

Então vamos todos parar de escrever código, ora bolas! Os requisitos é que interessam!

Nosso trabalho todo agora vai ser entender direito as necessidades do cliente. Há várias técnicas e ferramentas para fazer isso. Você pode tentar entender os requisitos usando diagramas, documentos de casos de uso e até um poster de papelão colado em uma parede na sala de desenvolvimento.

Ou então você pode usar — veja só — código.

Não precisamos separar as atividades de escrever código e analisar requisitos. A escrita do código pode muito bem fazer parte da análise de requisitos, assim como o tempo que se gasta escrevendo casos de uso ou pintando aquele poster lá.

Se o software está minimamente “pronto”, os clientes podem experimentá-lo, vê-lo funcionando e solicitar modificações quando necessário. Eles não podem fazer isso com casos de uso. Eles não conseguem ver os casos de uso funcionando até que alguém os transforme em código. Pode ser até pior: eles podem ver um diagrama (que também não funciona) e imaginar que vai funcionar de um jeito diferente do que a equipe de desenvolvimento imagina.

O famigerado código pode ser usado como uma ótima ferramenta para análise de requisitos. Nós somos programadores, não arquitetos. Não precisamos esperar os pedreiros levantarem o prédio para ver como vai ficar. No lugar dos pedreiros temos compiladores e interpretadores, não seres humanos. Arquitetos não podem se dar ao luxo de construir o prédio errado (bem que gostariam de poder fazer isso), por isso precisam investir bastante tempo nas especificações para ter certeza de que tudo vai funcionar como desejado. Nós não precisamos. Para um programador, derrubar o prédio e construir tudo novamente é tão simples quanto `make clean && make`. Ao invés de nos debruçar sobre especificações mortas, podemos observar como a coisa real se comporta. A coisa é chamada de software justamente porque é fácil (e barata) de ser modificada. Não tirar proveito da maleabilidade da nossa mídia é perda de tempo.

Então a lógica fica mais ou menos assim: o código não interessa porque o trabalho mais valioso é o de acertar os requisitos. Acertar os requisitos é descobrir o que o cliente precisa. Fica muito mais fácil descobrir o que o cliente precisa quando você tem software funcionando para mostrar. Software funcionando precisa de código. Logo, o código interessa.

Bom, na verdade o código não interessa tanto assim, mas precisamos desejar muita sorte para quem tentar entender os requisitos sem código.

Corre um boato novo dizendo que Rails é o novo ASP, mas isso não é exclusividade de Rails (nem de ASP): qualquer coisa pode ser o novo ASP, basta apresentá-la às pessoas erradas. Programadores ruins serão ruins usando qualquer tecnologia. Tecnologicamente falando, não há nada que se possa fazer para torná-los menos ruins. Não há como projetar uma tecnologia que os impeça de ser ruins. Não é com novas linguagens, bibliotecas ou frameworks que eles vão melhorar. Algo que talvez ajude são idéias novas, mas eles precisam estar abertos a elas. No fim das contas a transformação depende somente deles mesmos. Parece auto-ajuda mas é bem verdade.

Há basicamente duas maneiras de novas tecnologias influenciarem programadores ruins a escreverem software menos ruim. A primeira é tornar as boas práticas extremamente fáceis de modo que simplesmente pareçam o jeito natural de fazer as coisas. A segunda é tomar o caminho contrário e tornar práticas ruins mais difíceis ou feias de se fazer. Pode-se usar algo como vinagre sintático para fazer isso. O problema de tornar práticas não recomendadas mais feias é que os programadores ruins vão escrever o código feio e ignorar completamente a feiúra. Os olhos deles são incapazes de enxergar feiúra em um trecho de código. Se você quiser realmente seguir por este caminho, precisa dar um jeito de proibir por completo as asneiras mais gritantes.

Mas só é possível enxergar as mais gritantes.

Mesmo que você consiga evitar os piores erros, surgirão novas idéias igualmente burras. Você pode tentar bloquear essas também e continuar tentando proteger as pessoas delas mesmas até um certo ponto. Mas infelizmente não é possível proibir um idiota de estragar tudo. Os idiotas precisam estragar tudo. É a natureza deles. É isso que os define. É por isso que eles são chamados de idiotas. Não importa quantas bolas de chumbo você amarre aos pés deles, os verdadeiros idiotas vão arrumar um jeito de fazer besteira. Se sua tecnologia resolver seguir por este caminho, vai precisar proibir tanta coisa e ficar tão limitada que só os tapados serão atraídos. Aqueles que sabem o que estão fazendo simplesmente não aceitam trabalhar acorrentados.

Já que o caminho da proibição não é tão promissor, é melhor explorar a alternativa: tornar o “certo” idioticamente fácil. Desse modo, os bons profissionais serão atraídos pela elegância das soluções e vão começar a falar sobre a sua tecnologia. Com o burburinho todo mundo vai querer dar uma olhada nesse novo negócio de que os caras da moda andam falando tanto. As idéias ruins serão contidas por algum tempo, mas há um efeito indesejável que você não vai conseguir evitar.

Este efeito está intimamente ligado à maldição da popularidade. Mais popularidade significa mais gente e mais gente significa mais gente tapada. Sua tecnologia preferida simplesmente não pode conseguir se tornar popular e só atrair gênios da computação, eles não são muitos. Para ser popular ela vai precisar dos idiotas. E os idiotas têm um talento natural para estragar as coisas, lembra? Se você quiser ter uma tecnologia amplamente difundida, vai precisar aceitar que ela se torne o novo ASP. Não tem jeito.

Já há quem fale sobre a obsolescência das iterações como as conhecemos. Um dos maiores “culpados” por esse novo movimento é uma prática antiga da produção just-in-time: o Kanban. Mas este texto não é para falar de coisas tão novas assim. Isso aqui é sobre como boa parte da indústria ainda nem digeriu a idéia que veio antes: as iterações.

Mas espera aí. Todo mundo usa iterações, não?

Bom, na verdade não. Como podemos observar a partir de alguns relatos bem recentes, desenvolvimento de software em cascata ainda é realidade em muitos lugares. Pode parecer uma realidade bem distante para você, mas é algo bem próximo para essas pessoas. Tão próximo e tão incômodo que elas tomaram o tempo de sentar-se e escrever sobre o assunto. O pessoal do 1up4Developers até dedicou um site inteiro a isso. Eles deviam estar verdadeiramente sofrendo quando começaram isso.

A triste realidade é que não é tão incomum assim encontrar organizações onde uma “iteração” normalmente dura seis meses e onde é terminante proibido tocar em uma única linha de código enquanto a equipe não atravessar oficialmente a “fase de requisitos” (e talvez mais algumas outras fases depois dela). O pior é saber que o modelo da cascata nasceu somente como contra-exemplo (pdf), algo que deveria ser evitado tanto quanto possível. Não sei que seqüência de eventos esdrúxula consegue levar um modelo de contra-exemplo fabricado a prática padrão de toda uma indústria, mas foi o que aconteceu.

Felizmente, já existe uma solução para isto e ela, sem muita surpresa, atende pelo nome de iteração. Não iterações de seis meses para camuflar um processo em cascata, mas iterações de verdade que permitam feedback rápido e adaptação a mudanças. Antes que possamos começar a tornar as iterações obsoletas, precisamos apresentá-las a quem ainda não as conhece. Mais importante ainda: a quem acha que as conhece mas nunca viu nada além de desvirtuações do conceito.

Podemos até mesmo começar com cascatas iteradas. Já que eles parecem gostar da cascata, dividiremos os projetos em cascatas menores com entregas de software real ao final de cada ciclo. Todo mundo continua trabalhando do mesmo modo de sempre, mas agora os prazos para cada fase e o escopo da iteração como um todo serão reduzidos. A diferença é que os clientes terão software para observar mais cedo, algo real e bastante vivo que possam usar como base para novas idéias ao invés de serem obrigados a fazer especulações baseadas em documentos mortos. Certamente não é o ponto a que queremos chegar, mas quem disse que ia ser fácil?

Uma questão essencial para esta estratégia é o tamanho das iterações. Cascatas iteradas muito longas seriam somente casos especiais do processo de desenvolvimento anterior. Seis meses certamente é muito tempo e três meses ainda parece muito. A partir de um mês de duração começamos a conversar. Ainda é bastante longo, mas, novamente, é só um ponto de partida.

Depois disso o próximo passo provavelmente deve ser mostrar como representações intermediárias podem ser ineficientes. Novamente o encolhimento das iterações deve nos ajudar. Prazos de um mês já devem estar suficientemente difíceis de cumprir quando se tem representações intermediárias para criar e as equipes provavelmente já começaram a eliminar as práticas mais ineficientes neste ponto. Encolher as iterações para quinze dias deve dar conta de eliminar a maioria das ineficiências restantes. Você simplesmente não consegue produzir porções significativas de software funcionando se tiver que escrever treze documentos e aprovar cinco solicitações de mudança pra cada linha de código que precisar alterar.

Quando chegarmos a este ponto, será que deveríamos parar aí? A beleza deste processo de encolhimento das iterações é poder continuar diminuindo-as. Iterativamente, se você me permite. O limite será alcançado quando em uma iteração couber somente um requisito. Neste ponto, a única maneira de continuar encolhendo as iterações é encolher os próprios requisitos, tornando-os cada vez mais simples e atômicos.

Mas será que sua organização vai ter coragem para chegar lá?