Consertando Bugs Burramente

Consertando Bugs Burramente Por Joel Spolsky Terça-feira, 31 de julho de 2001 Qualidade de software, ou a falta dela, é uma coisa de que todo mundo reclama. Agora que tenho minha própria empresa decidi fazer alguma coisa a respeito. Nas últimas duas semanas nós paramos tudo na Fog Creek para poder embarcar uma nova versão incremental do FogBUGZ com o objetivo de eliminar todos os bugs conhecidos (eram cerca de 30). Para um desenvolvedor de software, consertar bugs é uma coisa boa. Certo? É sempre uma coisa boa, não? Não! Consertar bugs só é importante quando o valor de ter os bugs consertados excede o custo de consertá-los. Estas são medições difíceis, mas não impossíveis, de fazer. Vou lhes dar um exemplo. Suponha que você opera uma fábrica de sanduíches de manteiga de amendoim e geléia. A fábrica produz 100.000 sanduíches por dia. Recentemente, devido a introdução de alguns novos sabores (manteiga de amendoim com alho e geléia picante de Habanero), a demanda por seus produtos explodiu. A fábrica está operando na capacidade máxima de 100.000 sanduíches, mas a demanda está provavelmente próxima de 200.000. Não dá para você fabricar mais. E em cada sanduíche você tem um lucro de 15 centavos. Aí você perde US$15.000 por dia de lucro potencial porque não tem capacidade suficiente. Construir uma nova fábrica vai custar muito caro. Você não tem o capital, e tem medo que os sanduíches alho-apimentados sejam apenas uma moda que, com o tempo, vai passar. Mas ainda assim você está perdendo a US$15.000 por dia. Foi bom você ter contratado Jason. Jason é um garoto programador de 14 anos que "hackeou" os computadores que controlam a fábrica, e acredita achou uma maneira de acelerar a linha de produção do fator de 2. Algo a ver com overclocking que ele leu no slashdot. E que pareceu funcionar num teste piloto. Só uma coisa está impedindo você de implementá-la. É este pequenininho, minúsculo 'buguinho' que resulta em, mais ou menos, um sanduíche amassado por hora. Jason quer resolver o buguinho. Ele acha que o resolve em três dias. Você vai deixar que ele o resolva, ou vai implementar o software do jeito que está? Implementar o software três dias mais tarde vai resultar numa perda de US$45.000 de lucro. E vai lhe economizar, hã, o custo material de 72 sanduíches. (De qualquer forma Jason vai solucionar o bug três dias mais tarde). Bem, eu não sei quanto custa um sanduíche no seu planeta, mas aqui na terra, eles custam muito menos do que US$625. Onde eu estava? Ah, sim. Algumas vezes não a pena resolver um bug. Aqui vai outro bug que não vale a pena resolver: se você tem um bug que derruba seu programa quando você abre arquivos gigantescos, mas isso só acontece com aquele único usuário que usa OS/2 e que, até onde você sabe, nem mesmo acessa grandes arquivos. Bem, não o resolva. Coisas piores já aconteceram no mar. De modo similar eu deixei de dar assistência às pessoas com monitores de 16 cores ou pessoas que usam o Windows 95 sem sem nenhuma atualização em sete anos. Pessoas assim não gastam muito dinheiro em software. Confie em mim.

Mas, na maior parte das vezes, vale a pena consertar bugs. Mesmo se são bugs inofensivos, eles podem impactar a reputação de sua empresa e seus produtos, o que, a longo prazo, terá impacto significativo nos seus resultados. É difícil desfazer a reputação de ter um produto defeituoso. Quando você quiser liberar aquela versão .01, aqui estão algumas idéias para descobrir e resolver os bugs certos: aqueles que são economicamente interessantes de resolver. Primeiro Passo: Garanta Que Você Tem Conhecimento Dos Bugs. No caso do FogBugz, temos duas formas de fazer isto. Primeiro, registramos todos os bugs no nosso servidor de demonstração grátis, capturamos toda informação que pudermos, e enviamos por email todo pacote para a equipe de desenvolvimento. Isto resulta num impressionante número de bugs, o que é muito legal. Por exemplo, descobrimos um grupo de pessoas que escrevia coisas que não datas no campo "corrigir para". Nós não tínhamos uma mensagem de erro para este caso, isto simplesmente resultava numa falha fatal (o que, numa aplicação web, significa que você obtinha um erro horrível de IIS ao invés do que o que esperava). Oops. Quando eu trabalhava na Juno, nós tínhamos um sistema ainda mais bacana de coletar dados "do campo" automaticamente. Nós instalamos um controle usando a TOOLHELP.DLL de modo que cada vez que Juno sofria uma falha fatal, ele continuava vivo por tempo suficiente para despejar a pilha num arquivo de registro antes de ir para a cova. Na próxima vez que o programa se conectava à Internet para enviar correio, ele subia o arquivo de registro. Durante o teste beta, nós juntávamos estes arquivos de registros, organizávamos todas falhas fatais, e as colocávamos no banco de dados de rastreamento de bugs. Este processo descobria literalmente centenas de bugs fatais. Quando você tem um milhão de usuários, é impressionante o que pode falhar, freqüentemente resultado de condições severas de pouca memória ou por computadores de baixa qualidade (você pode soletrar Packard Bell?). Você poderia ter códigos como este: int foo( object& r ) { r.Blah(); return 1; } e você conseguiria falhas fatais porque a referência r era NULA, mesmo que isso fosse completamente impossível, não existe uma coisa como uma referência NULA, C++ garante isto, e você não tem que acreditar em mim mas quando você espera muito tempo e tem milhões de usuários e coleta religiosamente seus despejos de pilha, você encontrará falhas fatais em lugares como este e você não acreditará nos seus olhos. (E você não os consertará. Raios cósmicos, cara. Pegue um computador novo e desta vez não instale toda a barra de tarefas porreta que você encontrar. Caramba.) Outra coisa que fazemos é considerar que cada e todo pedido de suporte é evidência de um bug. Quando atendemos o pedido, tentamos imaginar o que poderíamos ter feito para eliminá-lo. Por exemplo, a forma antiga de configurar o FogBugz assumia que o FogBugz iria rodar com contas anônimas de usuários de Internet. Aquela era uma boa premissa para 95% dos casos, mas uma má premissa em 5% dos casos, e cada um desses 5 % de casos resultava num chamado para nossa linha de suporte. Por isso o modificamos a configuração para solicitar uma conta. Segundo Passo: Certifique-se Que Vai Receber Feedback Econômico Você pode não ser capaz de imaginar exatamente quão valioso é solucionar cada bug, mas há alguma coisa que você pode fazer: debite o "custo" do suporte técnico à unidade de negócio. No início dos anos noventa houve uma reorganização financeira na Microsoft em que cada unidade de produto passou a ser debitada do custo total de todas as chamadas de suporte. Com isso todas as unidades de produto insistiam que o PSS (o suporte técnico da Microsoft) lhes informasse regularmente a lista dos Dez Bugs Mais Importantes. Quando a equipe de desenvolvimento se concentrou neles, os custos do suporte técnico aos produtos despencou.

Isto entra em contradição com a nova tendência de deixar que os departamentos de suporte técnico paguem por suas próprias operações, uma coisa que a maioria das grandes companhias faz. Na Juno esperava-se que o suporte conseguisse equilíbrio financeiro pela cobrança do suporte técnico às pessoas. Quando se transfere o custo dos bugs para os usuários, você perde a capacidade limitada que teria de detectar os danos que estavam causando. (Em vez disto você consegue usuários irados que se ressentem de ter de pagar por seus bugs, que falam para seus amigos, e você não pode medir quanto isso lhe custa. Para ser honesto com Juno, o produto era gratuito, assim, pare de reclamar.) Uma forma de resolver ambos é não cobrar do usuário quando o pedido suporte foi causado por um bug do seu próprio produto. A Microsoft faz isto, e é bem delicada, eu nunca paguei por qualquer chamada para Microsoft :) Em vez disto, debite de volta ao produto os US$245 ou o que quer que sejam, hoje em dia, os custos do suporte de desenvolvimento a incidentes. Isso arrebenta seus lucros completamente para o produto que eles lhe vendem (muitas e muitas vezes), e cria exatamente o incentive econômico correto. Isso me faz recordar uma das razões porque os jogos em DOS eram um péssimo negócio... para conseguir que eles tivessem boa aparência e fossem rápidos, você geralmente precisava de drivers de vídeo estranhos, e uma única chamada ao suporte técnico sobre drivers de vídeo arrebentava o lucro que você poderia fazer com 20 cópias do seu produto, assumindo que a Egghead e a Ingram e o anúncio na MTV já não tivessem engolido todos os seus ganhos. Passo Três: Determine Quanto Vale Para Você Consertar Todos Eles. Na Fog Creek Software, bem, somos uma empresa pequena (exceto nas nossas cabeças), e a equipe de desenvolvimento só recebe as chamadas de suporte técnico. O custo andava em torno de 1h por dia, o que, baseado no preço de nossa consultoria, resulta em algo em torno de US$75.000 por ano. Tínhamos certeza que poderíamos baixar este custo para 15 minutos por dia se resolvêssemos todos os bugs conhecidos. Usando números muito grosseiros aqui, isso significaria que o valor presente líquido da economia seria algo em torno de US$150.000. Este valor justificaria 62 dias de trabalho: se você puder fazê-lo com menos de 62 pessoas-dias, vale a pena fazer. Usando a funcionalidade conveniente incluída no FogBugz, calculamos que levaria vinte pessoasdias (duas pessoas por duas semanas) para solucionar tudo-ou seja US$48.000 “de gasto” para um retorno de US$150.000, o que é um excelente retorno baseado apenas na economia em suporte técnico. (Observe que se pode utilizar o custo do programador e suas despesas gerais (overhead) em vez do nosso preço de consultoria e chegar ao mesmo resultado de 3:1, já que eles se cancelariam). Eu nem mesmo comecei a contar o valor de ter um produto melhor, mas posso começar a fazê-lo, também. Nós tivemos 55 falhas fatais no servidor de demo durante o mês de julho com o código antigo, representando 17 de usuários distintos. Você pode imaginar que ao menos uma dessas pessoas decidiu não comprar o FogBugz porque eles pensavam que era muito cheio de bugs quando eles rodaram o demo (embora eu não tenha estatísticas reais para confirmar.) De qualquer forma a perda em vendas estava nos custando alguma coisa entre US$7.000 e US$100.000 em valores presentes. (Se você for muito sério, não seria muito difícil conseguir o número real). Próxima pergunta. Você pode cobrar mais por um produto com menos bug? Isto acrescentaria um bocado de valor à depuração. Suspeito que nos extremos, o número de bugs afeta o preço, mas eu estou muito pressionado a pensar em um exemplo do mundo de software de prateleira onde isto tem sido o caso. Por Favor Não Me Batam! Inevitavelmente as pessoas lêem ensaios como este e chegam a conclusões idiotas, como, Joel não acha que você deve consertar bugs. Na realidade eu penso que para a maioria dos tipos de bugs que a maioria das pessoas consertam, existe um claro retorno sobre o investimento. Mas pode haver mesmo um valor monetário maior para fazer algo que não seja consertar cada último bug. Se você

tiver que decidir entre consertar o bug do sujeito do OS/2 e adicionar uma nova funcionalidade que vai vender o 20.000 cópias do seu software para General Electric, bem, desculpe-me a pessoa do OS/2. E se você for estúpido o suficiente para pensar que é mais importante consertar o OS/2 do que incluir a funcionalidade da GE, talvez seus competidores não pensem assim e você irá à falência. Dito isso, eu sou um otimista, e acredito que há muito valor escondido em produzir produtos de muito alta qualidade que não é muito fácil de capturar. Seus funcionários vão ficar mais orgulhosos. Menos clientes vão lhe enviar de volta seu CD pelo correio depois de assá-lo no microondas e cortá-lo em pedacinhos com um machado. Assim eu tenho a tendência de errar para o lado da qualidade (na verdade, nós consertamos todos os bugs conhecidos no FogBugz, não apenas aqueles de grande repercussão) e ficamos orgulhosos disso, e nos sentimos confiantes, com a completa eliminação dos erros do servidor demonstração, que temos um produto muito sólido. Ah, e aliás: Minha empresa, a Fog Creek Software, oferece estágios pagos em desenvolvimento de software para bons estudantes universitários. Os estágios são em Nova York. Alojamento, almoço e outras coisas grátis. E você vai trabalhar em software real, comercial e junto com os mais inteligentes desenvolvedores neste negócio. Saiu meu novo livro! A Apress acaba de publicar uma nova coletânea de 36 ensaios do Joel on Software, denominado propriamente More Joel on Software . Pegue o seu hoje! Disponível na Amazon.com ou em qualquer lugar que venda bons queijos.

Sobre o autor: Sou seu anfitrião, Joel Spolsky, um desenvolvedor de software na cidade de Nova Iorque. Desde 2000 escrevo sobre desenvolvimento de software, gerência, negócios e a Internet neste espaço. Meu trabalho do dia-a-dia é a Fog Creek Software, que publica o FogBugz – o software, de nome estúpido, para o acompanhamento esperto de bugs e o Fog Creek Copilot – que oferece a forma mais tranqüila de proporcionar suporte remoto via Internet, sem nenhuma instalação ou configuração. Sobre o Tradutor: Paulo André de Andrade é Engenheiro Eletrônico e Diretor da OLYMPYA TI, responsável, no Brasil, pela comercialização dos softwares da Fog Creek. Paulo André atua em Informática desde 1971 em setores que vão de Engenharia de Produtos de Hardware, Desenvolvimento de Hardware e Software, Desenvolvimento de Negócios, Marketing e Vendas de Software e Consultoria em Gerência de Projetos e Serviços de Informática. OLYMPYA: Com base no Rio de Janeiro a OLYMPYA foi fundada em 2000 por Paulo Mattos e Paulo Mattos Sr. com foco no desenvolvimento de plataformas de jogos MMO (Massively Multiplayer Online) Sports Strategy Games e em Consultoria em Tecnologia da Informação. A Olympya Software - www.olympya.com.br - é também a representante exclusiva no Brasil e Portugal da FogCreek, http://www.fogcreek.com.br empresa fundada pelo Joel Spolsky Você pode usar gratuitamente por 45 dias o produto FogBugz 7.0, totalmente web, para gerencia de projetos e outras funcionalidades, visitando o link: http://try.fogbugz.com Para treinamento em como fazer melhores softwares você pode aprender mais sobre outro produto da FogCreek, já em Português: http://www.pdfcoke.com/doc/29112680/Make-Better-Software-V1