Mergulhando no Caos

Há basicamente dois tipos de organizações que procuram uma certificação de qualidade de processo: aquelas que querem mudar seus processos (de preferência para melhor) como efeito colateral e aquelas que não querem mudar nada, mas querem a certificação como diferencial competitivo.

O interessante é que certificações de processo só dizem respeito a – adivinhem só – processos. As organizações que emitem os certificados não se comprometem com a qualidade do produto. Um certificado desses quer dizer somente que alguém é organizado. O problema é que você pode saber que alguém é altamente organizado e nunca conseguir arrancar um bom produto dele. Ele pode te vender os piores pesadelos que sua imaginação possa conceber, mas vai fazer isso de modo completamente controlado.

Sério, é verdade. O grande trunfo das certificações de processo é que acreditamos que um processo de qualidade produz resultados de qualidade. Não há nada de estranho nisso. Em alguns casos isso realmente acontece.

Em outros não.

O diferencial competitivo verdadeiro, a qualidade de produto, não é alcançado por certificações. Talvez elas não cheguem nem perto disso. A melhor forma de avaliar a qualidade de um produto ou serviço é perguntar a seus clientes. Para eles o processo é um pequeno detalhe, um fator mínimo. Talvez isso seja decepcionante para quem está à procura do processo ou metodologia perfeita, mas é verdade.

Ao invés disso, o verdadeiro fator de sucesso pode estar em locais quase inexplorados, como um tesouro escondido no lugar mais óbvio. Um desses fatores por muitas vezes ignorado é a equipe. Bons profissionais bem motivados podem operar milagres. Uma equipe de profissionais bons e motivados sem nenhum processo formal é capaz de fazer produtos de alta qualidade. Isto pode não acontecer com muita freqüência, mas é possível. Porém é muito mais raro uma equipe de profissionais ruins ou desmotivados com um ótimo processo fazer algo de qualidade. Ainda não foi inventado nenhum processo capaz de conduzir esta última espécie ao sucesso. E se eu tivesse que apostar, diria que nunca vai ser.

Cada vez mais me convenço que estes são dois ingredientes essenciais dentro do caldeirão que produz o sucesso. A má notícia é que nenhum dos dois é fácil de se conseguir.

Bons profissionais são artigos raros e valiosos, tão disputados quanto um copo de água no deserto e criar motivação é um desafio por si só. Motivar bons profissionais é uma tarefa apenas para os mais insanamente destemidos.

Estes times de elite não vão trabalhar só por dinheiro. Claro que é preciso remunerá-los bem, mas esta é a menor parte da questão. Bons profissionais vão querer superar desafios, tomar decisões estratégicas e resolver problemas interessantes. Eles não vão ser seduzidos por escritórios luxuosos nem por algumas palavras da moda espalhadas a esmo em propostas de emprego.

Pelo menos não os verdadeiramente bons.

Você começaria a construir um prédio sem antes ter uma especificação detalhada?

Eu com certeza não me arriscaria. Mas tenho mais uma pergunta: se você pudesse construir um prédio e reconstruir partes dele livremente a custo quase zero, você esperaria uma especificação detalhada para começar a construir?

Eu também não.

Desenvolver software é muito mais parecido com a segunda do que com a primeira situação e é por isso que esta metáfora de construção não pode ser levada muito longe. Ao contrário dos produtos da construção civil, é fácil e barato mudar uma parte ou outra de um sistema mesmo que ele já esteja em produção, é fácil até trocar a ordem dos andares. Claro que é mais barato fazê-lo em fase de desenvolvimento, mas a diferença de custo pode ser controlada e mantida a níveis razoáveis. A principal razão deste baixo custo não é nenhum segredo: software não é construído por pessoas.

Ao invés disso, as pessoas apenas especificam software utilizando coisas chamadas de linguagens de programação. A parte da construção propriamente dita — a montagem a partir de uma especificação — é feita automaticamente por ferramentas como compiladores e interpretadores. No mundo do software, os construtores são coisas como estas e o tempo de trabalho deles é muito mais barato que o dos construtores humanos. Na verdade, pode-se encontrar alguns excelentes a custo zero.

É como se houvesse máquinas distribuídas gratuitamente que fossem capazes de receber um conjunto de plantas e construir rapidamente um prédio ou uma ponte sem nenhuma intervenção humana. Infelizmente, os engenheiros civis não têm essa sorte. Mas seria estupidez se os engenheiros de software não se aproveitassem dela para fazer seus produtos e colocá-los rapidamente à disposição dos clientes.

Ainda bem que eles fazem isso.

Bom, pelo menos alguns fazem.

Estou lendo O valor do amanhã de Eduardo Giannetti. Ele é um economista (não um programador, como a maioria dos autores que leio) e este livro em particular é sobre trocas e negociações intertemporais. Quando escuto dizer que um economista está falando de trocas intertemporais, não consigo evitar pensar em juros aplicados ao mercado financeiro. O que achei interessante é que Giannetti vê os juros em um contexto maior, identificando-os, por exemplo, na biologia. Aparentemente isto não tem nada a ver com software ou tecnologia, mas é por isso que o subtítulo do blog fala em devaneios.

Acontece que existe no cérebro dos programadores um mecanismo que faz ele relacionar (quase) qualquer coisa que lê com seu trabalho. Talvez os mais antenados já tenham identificado aonde quero chegar: o conceito de dívida de projeto, que talvez você já conheça pelo termo em inglês design debt.

Giannetti destaca a diferença entre envelhecimento e a senescência, dois mecanismos geralmente referenciados apenas pelo primeiro termo. Envelhecimento é o simples passar do tempo, o mecanismo pelo qual avançamos em idade e experiência. Senescência é o mecanismo que debilita um organismo com o passar do tempo. A senescência é o custo pago pelo vigor da juventude. Assim como os juros financeiros, a senescência é um custo pago na velhice (futuro) em troca de um benefício na juventude (presente). O organismo dispõe de tanta energia na juventude justamente porque vai pagar por ela na velhice.

O universo do desenvolvimento de software não está livre dos juros. Para cada atalho que tomamos no presente, cada “jeitinho” que damos, serão cobrados juros no futuro. Assim como no mercado financeiro, a quantidade de juros envolvidos na transação depende do tamanho do empréstimo que tomamos. Assim como não se deve rolar muito as dívidas financeiras, não se deve postergar demais o pagamento das dívidas de projeto. Quanto mais tempo correr, mais juros terão que ser pagos. Isso é um bom negócio para quem empresta dinheiro, mas não para quem produz software.

Todos nós queremos sistemas que durem bastante tempo e que continuem gerando dividendos: sistemas velhos. Mas ninguém quer um sistema senil, um no qual a receita não compense o esforço gasto com o pagamento de juros. Então é melhor consertar hoje aquelas pequenas gambiarras que você fez ontem. Cada vez que pensar “puxa, isso deveria mesmo ser feito de outro jeito, mas vou fazer desse jeito aqui para ir mais rápido”, não pare na parte do pensamento. Uma abordagem muito mais indicada é fazer do jeito rápido, ter testes que comprovem o funcionamento e consertar para o jeito certo.

Nota: O Motiro foi oficialmente lançado nesta segunda-feira. Pensei em fazer um post para anunciar isso, mas este blog já está tão infectado com notícias sobre Motiro que preferi fazer somente esta notinha aqui. Maiores informações (e links para o código-fonte e downloads) no blog do projeto.

Tenho uma confissão a fazer. Hoje eu apaguei umas 20 linhas do código de um sistema.

Afinal quem seria desumano a ponto de apagar um trecho de código em que investiu tempo e esforço para escrever? Quem em sã consciência cogitaria esta possibilidade?

Mas eu tive minhas razões. O trecho que eu apaguei é o que eu chamaria de solidificação mineral de código indevida. Sabe aqueles trechos de código que estão ali mas você não sabe para que diabos escreveu aquilo? Você passa um bom tempo imaginando qual a utilidade daquilo e não consegue se lembrar nem elaborar uma hipótese plausível. O trecho de código é quase um apêndice do seu sistema. Está lá. Funciona. Mas ninguém usa para nada.

Este anti-padrão foi identificado por William Brown, Raphael Malveau, Hays “Skip” McCormick e Thomas Mowbray no livro AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis e observado por milhares de programadores em uma quantidade astronômica de projetos. Os autores do AntiPatterns chamam isso, sugestivamente, de bloco de lava. O nome é uma alusão à erupção de um vulcão. Depois que passa a fúria da lava, ficam alguns blocos solidificados que não servem para muita coisa.

O código que eu apaguei hoje não era exercitado por nenhum teste do projeto (não estou usando nenhuma ferramenta para monitorar a cobertura de código, mas executei os testes após a exclusão do código e tudo continuou tão verde quanto antes). Além disso, eu não consegui pensar em nenhuma utilidade para aquele código mesmo tentando bastante. Então eu respirei fundo, apaguei o código e enviei a modificação para o repositório central. Até agora ninguém reclamou. E se reclamar vou pedir que escreva um teste que demonstre a utilidade do código. Isso vai impedir que o próximo programador desavisado apague tudo novamente.

Cada linha de código de um sistema em evolução (o que engloba a maior parte deles) aumenta o custo de manutenção. É mais uma linha que vai precisar ser lida, compreendida e testada. É como se o projeto fosse uma mala e as linhas de código as peças de roupa. Cada peça de roupa colocada na mala é um peso a mais que precisa ser carregado. Uma camisa ou um par de meias sozinhos não pesam muito, é quando eles se juntam que a mala fica pesada. Ao apagar o código, eu optei por carregar menos bagagem.

Talvez eu não esteja tão louco quanto pensei.

Acho que se fizermos uma pesquisa sobre que práticas de XP são mais utilizadas ou fáceis a metáfora tem grandes chances de ficar segurando a lanterna. 8 em cada 10 pessoas (aviso logo que estou chutando) acham que sua aplicação é questionável. Porém, a grande surpresa é que elas estão sim utilizando metáforas o tempo todo para desenvolver software.

A informática é um campo construído sobre o abstrato e virtual. Metáforas são um excelente mecanismo para entender estas peças abstratas e muitas delas têm sido historicamente usadas com sucesso. Hoje em dia falamos naturalmente de ‘área de trabalho’, ‘fluxo de dados’, ‘rede’, ‘pool de recursos’, ‘pipes (canos)’, ‘crawlers’ ou outros termos.

Na minha opinião a grande dificuldade de se usar a metáfora é saber elaborar uma que seja útil e duradoura. Isto dificulta, mas não impede, seu papel como ferramenta de comunicação. Além disso, muitas das metáforas que usamos acabam nascendo naturalmente durante o processo. Seja em uma conversa informal entre pares ou durante a escrita de um pedaço de código.

Outro perigo eminente é o risco da metáfora ser sobre-utilizada, ou seja, forçada para além de onde ela é aplicável. Em alguns casos isso é detectável, pois a coisa começa a ficar um pouco ridícula, em outros casos a fronteira pode não ficar clara e levar a decisões incertas. Há pouco tempo hove uma discussão na lista de XP sobre metáfora, destaco uma mensagem de Tim Haughton em que ele relata uma metáfora bem sucedida que foi sobre-utilizada por alguns.

Como tudo em XP, a utilização da metáfora é algo pequeno e pontual que influencia no todo e, talvez por isso, fica invisível a muitos olhos. Eu como xispista acredito que o todo é maior que a simples soma das partes. É assustadora a diferença que as interações entres as partes podem fazer nesta equação.

Há algum tempo — não sei bem certo quanto, mas o suficiente para que eu possa dizer ‘há algum tempo’ — venho acompanhando a evolução de XP como processo de desenvolvimento. Muitas vezes as práticas são um pouco polêmicas, precisando de um pequeno trabalho de convencimento para vencer a inércia inicial. Uma parte das pessoas acha que é tudo uma bagunça só, que coisas assim tão simples não podem dar certo. Outra parte está à procura de alternativas a processos um tanto quanto cerimoniosos. Estas últimas pessoas estão inclinadas a mudar, mas talvez não queiram arriscar tudo jogando o antigo processo fora e começando a usar um ‘processo novo que estão usando por aí’ do zero.

Para ambas as partes, meu conselho é

Adote XP do jeito XP.

Se você quiser apenas testar uma abordagem metodológica nova, se já se decidiu por mudar o processo antigo ou se não possuía nenhum processo e quer adotar algum, o jeito XP é fazer tudo incrementalmente. Começar com partes pequenas e adicionar outras parte também pequenas gradativamente, deixando que a interação entre elas gere um todo maior que a soma das partes. E fazer isto tudo ‘na vera’ e sempre pensando por que uma coisa ou outra não está dando resultados em pouco tempo.

Sim, pouco tempo. As práticas de XP foram especialmente projetadas para que apresentassem resultados após pouco tempo de adoção e, além disso, um fator decisivo para a adoção é que elas são recompensantes também em termos psicológicos. Você simplesmente se sente bem de ver a ‘luzinha’ verde que indica os testes passando, de saber que poderá refatorar o que não estiver agradável, de poder trabalhar lado a lado com todos os seus pares e de todos eles conhecerem tanto do sistema quanto você.

Dan Bunea publicou uma mensagem na lista de XP que esclarece um pouco essas dúvidas. É interessante ler também o restante das mensagens relacionadas, a discussão por lá está bastante produtiva. Meu resumo da idéia dele é: convença a você mesmo, convença a seus pares, convença a gerência e, finalmente, convença o cliente. E faça tudo isso praticando, colhendo os frutos eXtremamente ráPido.

Você já começou a acolher a mudança?

Dia desses, eu estava perdido na web, lendo sobre refactoring. Para quem está envolvido com desenvolvimento ágil, o vocábulo já paz parte do jargão diário e quem pratica XP provavelmente não consegue imaginar como existe gente que não usa a técnica deliberadamente.

O novato desavisado tende a reduzir tudo que escuta ao que lhe parece a essência da coisa, para simplificar e tentar entender o assunto. Falar em ‘melhorar a estrutura do código sem modificar seu comportamento externo’ pode parecer a este novato uma mera desculpa para ficar mimando o código, dando mais atenção a ele do que o estritamente necessário. Refatorar está, aparentemente, ligado a ‘consertar o que não está quebrado’.

Aparentemente.

Na verdade, não tem nada a ver com isso. Refactoring é um dos processos que nos permite evitar ter todas as idéias sobre a arquitetura do sistema no início do desenvolvimento. Refactoring permite modificar o design do software segura e rapidamente quando necessário (e somente quando necessário). Com refactoring, podemos nos permitir aprender sobre o sistema ao mesmo tempo que o desenvolvemos. Não precisamos nos limitar a soluções pré-fabricadas (mas podemos fazer uso delas), muito menos projetar todo o sistema antes de começar a codificar.

Vantagens demais para ser verdade? Acho que não. Na verdade já fazemos isto todos os dias. Fazemos isto, por exemplo, quando identificamos uma lógica de execução comum para duas rotinas e dela extraímos uma terceira. Ou então quando movemos responsabilidades de uma classe para outra, como mostra Martin Fowler neste exemplo do seu ‘Refactoring: Improving the design of existing code’ (que já possui tradução para nosso querido idioma pátrio).

Digamos que foi feito um sistema para uma locadora de filmes (sim, Martin Fowler também tem seus momentos de baixa criatividade). Este sistema foi feito por uma equipe ainda não iniciada às artes do refactoring e que também não entendia muito de herança e polimorfismo na época. O cálculo de débito do cliente é calculado na classe Customer com auxílio do seguinte método privado, responsável pelo cálculo de débito proveniente de uma única locação.

class Customer {
  ...
  private double amountFor(Rental aRental) {
    double result = 0;
    switch (aRental.getMovie().getPriceCode()) {
      case Movie.REGULAR:
        result += 2;
        if (aRental.getDaysRented() > 2)
          result +=
            (aRental.getDaysRented() - 2) * 1.5;
          break;
      case Movie.NEW_RELEASE:
        result += aRental.getDaysRented() * 3;
        break;
      case Movie.CHILDRENS:
        result += 1.5;
        if (aRental.getDaysRented() > 3)
          result +=
            (aRental.getDaysRented() - 3) * 1.5;
        break;
    }
    return result;
  }
  ...
}

Este método é utilizado por outro maior que calcula todo o débito do cliente. A equipe que desenvolveu o sistema original teve ao menos o cuidado de extrair este método para evitar que o maior ficasse exageradamente grande, mas não notaram que o novo método na verdade não pertence à classe Customer. Note que o método só mexe com atributos da classe Rental e pertence logicamente a ela. Podemos mover o método para ela e chamar apenas rental.getCharge() no local original sem perder o significado.

Depois disso, é hora de transformar esse switch altamente suscetível a erros em uma chamada de método da classe Movie, talvez utilizando o padrão State. Refactoring é a simples aplicação de modificações pequenas como estas de modo controlado. Acho que já deu pra pegar a idéia.

Talvez tenha alguém dizendo: “Mas isso não pode dar certo! As mudanças são pequenas demais para serem signiticativas.”

Sim, as mudanças são pequenas. A força delas não vem da utilização isolada, mas contínua. Aqui o todo é maior do que a soma das partes, por causa da interação entre as várias mudanças.

Mas não nos limitemos a alguns exemplos. Fazer isso seria agir como o novato do qual falamos. Começar a aplicar refactoring na prática é tão fácil quanto não se limitar a duplicar um trecho de código deliberadamente, mas capturar a duplicação e escrever o caso geral. Isto pode se concretizar na extração de uma rotina, na identificação da oportunidade de usar um design pattern ou de muitos outros modos que vamos descobrindo quando tentamos.

Quem me conhece sabe que gosto um pouco de música e outro pouco de desenvolvimento de software. Por isso eu gosto de usar a música para entender o que acontece nesse mundo complicado cheio de aplicações, frameworks, sistemas e metodologias que é o mundo do software.

Quando os Ramones inventaram o punk rock lá pela década de 70, eles quiseram simplificar o rock ‘n roll, aproveitando a experiência adquirida pela comunidade em 20 anos de história. Eles se perguntaram: ‘Qual é a essência do rock por trás desses solos infindáveis e arranjos complicados?’ e a resposta foi o trio baixo, guitarra e bateria e canções simples e curtas.

O que os autores do manifesto ágil e centenas de programadores (eu me arriscaria a dizer milhares) em todo o mundo fizeram foi bem parecido. Eles se perguntaram ‘Qual é a essência do desenvolvimento de software por trás dessas inúmeras ferramentas e processos complicados?’ e despiram a prática comum em busca das necessidades fundamentais. O interessante é que a maioria dessas necessidades podem ser supridas por práticas simples, desde que saibamos como e porquê utilizá-las.

O ser humano tem uma certa tendência a se acomodar. Quando estamos acostumados com alguma forma de trabalho, tendemos a acreditar que ela é ‘A’ solução. Até mesmo quando ainda não tivemos tempo de nos acostumar a nenhuma forma de trabalho, tendemos a aceitar a forma que parece a princípio mais ‘séria’. E, para o explorador incauto, a ‘seriedade’ aqui quase sempre é sinônimo de formalidade.

Algumas pessoas acreditam que o punk rock talvez tenha ido longe demais na simplificação. Uma parte dessas pessoas estava acostumada demais com o ‘rock antigo’ para serem capazes de avaliar imparcialmente o novo movimento. A outra parte simplesmente não entendia a razão daquilo e preferia confiar no que parecia mais ‘elaborado’.

Se você é um dos que acha que o desenvolvimento ágil é simples demais para funcionar, mas está intrigado por ouvir tanto falar nisso, os links nesse post são um bom ponto de partida. Boa sorte.