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 pessoas-
dias (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.scribd.com/doc/29112680/Make-Better-Software-V1