Good Enough Software
 J. Antão B. Moura - UFCG/CCT/DSC – antao@dsc.ufcg.edu.br

A filosofia popular americana explica a realidade cotidiana quando coisas indesejáveis acontecem, com um simples “shit happens”. Esta máxima filosófica parece estar sendo trazida agora, como base para o conceito de “Good Enough Software” (GES) em Engenharia de Software. O conceito é recente.

Por conta da novidade, não se recrimine se GES é desconhecido para você. Na verdade, há ainda poucos artigos sobre o assunto. Um dos primeiros artigos apareceu em Communications of the ACM (janeiro 1994). Parece ter sido Ed Yourdon, dedicando um capítulo no seu livro Rise and Ressurrection of the American Programmer (da editora Prentice Hall, 1996), que conseguiu destaque para o tema.

Apesar da novidade do conceito, ele já interessa a programadores e produtores de software, por conta das implicações econômicas. Com GES, propõe-se essencialmente liberar uma versão do software para o contratante, uso interno ou para o mercado que seja “útil o suficiente” (“good enough”), mesmo que ele ainda apresente defeitos, erros ou comportamento indesejável esporadicamente. Defensores da aplicação de GES argumentam que um software não necessita estar livre de defeitos/erros para ser útil. Obviamente, se uma versão deste software é liberada antes que todos os “bugs” conhecidos sejam removidos, se produzirá a versão mais rapidamente, reduzindo a espera dos seus usuários ou o seu “time-to-market” (prazo de liberação para o mercado) e conseqüentemente, o esforço de testes e de (re-)codificação. Reduzem-se custos obviamente, investimentos.

A Microsoft  parece ser um dos produtores de software que adotam o conceito de GES. O MS-Word 7.0 para o MS-Windows 95 por exemplo, apresenta o defeito (dentre outros) de vir a danificar o arquivo-documento (irreparavelmente) na formatação de índice de tópicos. Neste caso, o princípio de “codificação defensiva” da Engenharia de Software (por quê não providenciar cópia de backup sobre a qual seria gerado o índice?) passou ao largo, reduziu-se o “time-to-market” do produto. Deixou-se para o usuário eventualmente afetado, invocar a máxima filosófica americana, para seu consolo. GES parece que foi aplicado também na liberação da tecnologia ActiveX da Microsoft. Segundo comentários de Miko Matsumura – evangelista da linguagem Java – no NETWROK+INTEROP 97 (Cingapura, abril 97), bugs remanescentes no ActiveX resultam em quedas do Internet Explorer, emprestando-lhe o apelido de “Internet Exploder”.

Segundo James Bach da ST Labs Inc., consultor da Microsoft (na revista Computer, agosto 97): “A Microsoft inicia cada projeto na certeza de que escolherá liberar com bugs conhecidos. Esta estratégia funciona para a Microsoft porque ela sabe como liberar com os bugs certos” (!?!?). O livro Testing Computer Software de Cem Kaner (da editora International Thomson Press, 1993) se refere ao adiamento de consertos de bugs como prática rotineira da empresa.

O uso de GES como paradigma de desenvolvimento não parece ser limitado à Microsoft. O próprio sistema-demonstração de Matsumura no NETWORLD+INTEROP 97 apresentou problemas mesmo usando o browser da Netscape – o qual não tem componentes ActiveX.
A INTEL liberou o Pentium com problemas de cálculos de ponto flutuante. A Intuit (produtora americana) reconheceu que seu pacotes de software financeiro perdiam dados ao interagirem. Código produzido por programadores individuais não raro apresenta problemas que não são consertados deliberadamente. Você deve conhecer alguns exemplos. Procedimentos ou seqüências de comandos que evitam executar parte do código com problemas (os chamados “work arounds”) são freqüentemente propostos e adotados como “soluções”.

A questão importante aqui é que os defeitos/problemas são conhecidos e deliberadamente, não consertados. É importante assim, distinguir claramente GES do modelo de “funcionalidade incremental” para desenvolvimento de software, proposto na Engenharia de Software. Com este modelo e por pressões econômicas e/ou mercadológicas (por exemplo, concorrência forte ou fraca), se decide liberar uma versão preliminar do software com limitações funcionais (p.ex., um processador de textos sem verificação ortográfica). Versões futuras acrescentarão funcionalidade ao produto. O modelo incremental não advoga liberar uma versão com bugs. O conceito GES, o qual parece se tornar paradigmático, é essencialmente um modelo de “funcionalidade + qualidade incrementais”.

Alguns cínicos como também alguns defensores mais ferrenhos e inflexíveis do formalismo das normas na família ISO 9000, dizem que o GES consiste em se oferecer o mínimo de qualidade pela qual o cliente ainda estará disposto a pagar algum dinheiro. Esta definição visa chocar já que deixa implícita a facilidade com que GES pode levar o empreendedor de software a passar à “aplicação de golpes” nos clientes. Ela contudo, ao contrastar o “realismo”  de GES com o “idealismo, normalismo e formalismo” da Engenharia de Software tradicional, serve bem para ilustrar pontos essenciais para o sucesso financeiro do desenvolvimento de software.

Primeiro, o GES destaca a componente de custo do processo de desenvolvimento. O custo “ideal” será sempre maior do que o orçado e investimento disponível. Se você insistir no “ideal” poderá inviabilizar o empreendimento (no caso de software-houses que desenvolvem seus próprios produtos) ou o contrato (software sob encomenda), abrindo espaço para a concorrência.

Segundo, a aplicação de GES é mais “confortável” na ausência ou fragilidade da concorrência. A Microsoft com o Windows 9* e a Intel com o Pentium, fizeram o que fizeram devido ao “virtual monopólio” que cada uma tem no setor que atua. No cenário de concorrência acirrada, pode-se ainda se nortear por GES, mas a escala para se medir “good enough” tem que ser muito mais criteriosa. O GES neste cenário é uma proposição mais arriscada.

Terceiro, “qualidade” (isto é, menos defeitos) é uma medida situacional e subjetiva. Na parte situacional, o cliente pode até aceitar um produto com defeitos se não houver alternativa (em termos de suporte, plataforma, preço). Quanto à subjetividade, a qualidade é dependente do mercado (tanto da oferta quanto da procura). Software para suporte à produção corporativa requer mais qualidade do que um outro software para simples automação de escritório. A Microsoft não consegue o mesmo resultado ao aplicar GES ao MS-Word (mercado desktop, não crítico) e ao NT (rodando em servidores corporativos). A medida “good enough” para o NT é muito mais alta do que aquela aceitável para o Word. A aceitação do GES é ainda dependente do fornecedor (isto é mais verdade no Brasil com a nossa inclinação de privilegiar produtos importados). Você acha que o mercado reagiria com a mesma benevolência  (ou a fatalidade do “shit happens”) se o software em questão fosse de uma empresa brasileira e não da Microsoft?

Mas como determinar se um software está “good enough” (isto é, bom o bastante) para ser liberado? James Bach (o consultor da Microsoft referenciado mais atrás) traz umas dicas adaptadas aqui:

-	Não há problemas/defeitos críticos
-	Os benefícios, mesmo na presença de defeitos, são suficientes e tem maior impacto que os defeitos
-	Na avaliação geral, tentar melhorar ainda mais o software na versão atual, possivelmente trará mais prejuízos para o fornecedor e clientes do que ganhos.

É importante notar que os usuários potenciais (ou já existentes) do software podem e devem ter influência na determinação de “good enough”. A interferência deles pode acontecer no teste beta ou melhor, de usabilidade. Teste de usabilidade pode ser encarado como “Good Enough Testing” de fato, do ponto de vista do usuário. Os questionários dos testes de usabilidade sempre podem incluir perguntas do tipo: “você compraria o produto do jeito que ele se encontra?”; “as suas sugestões de melhorias podem ser deixadas para uma futura versão?”.

É importante também, notar que funcionalidade, qualidade e custos (financeiros ou em “time-to-market”) – os quais formam o tripé de GES – são interdependentes de forma negativa. Ao tentar alterar um dos pés, os outros são afetados negativamente. Por exemplo, aumentar funcionalidade (escrevendo mais código) normalmente introduz mais bugs, os quais baixam a qualidade e aumentam o custo. Além do mais, a relação entre os pés não é linear. Fique alerta portanto, para o grau de complexidade envolvido em alterar o tripé para ajustar o nível de “good enough”.

A questão de qualidade (ou defeitos) parece não ser a mais crítica, do ponto de vista do usuário. De acordo com Capers Jones, especialista em métricas para Engenharia de Software, o usuário (a nível de gerência) está mesmo é preocupado com custo e o “time-to-market” de nova versão (uma vez que estes dois itens se alojam nos dois primeiros lugares em suas preocupações, enquanto qualidade ocupa o quarto ou quinto). Se assim mesmo for, parece que GES deve mesmo ser o paradigma a adotar.

A adoção de GES como decisor / avaliador de riscos no processo de produção de software comercial deverá se fortalecer entre grandes empresas americanas do setor. Estas empresas abominam o “moralismo” e chatice de Engenharia de Software “tradicional” e de normas do tipo ISSO 9000. O conceito de GES parece estar sendo tomado como bandeira e remédio por elas e por praticantes de Engenharia de Software que se vêm às voltas com dificuldades e pressões de “roadmaps” de funcionalidade evolutiva e de “backlogs” de desenvolvimento.

O GES detona a premissa de Engenharia de Software de que se deseja produzir software de qualidade dentro do prazo e orçamento previstos – relegando tal premissa à utopia ou projetos muito especiais de certos sistemas críticos (por exemplo, aplicações na área de saúde, militares, aeroespaciais, etc). Por conta disto, é assunto controverso.

No final das contas, você deve ou não adotar GES? Para responder a esta pergunta, consulte seus usuários, examine o poder de fogo da concorrência, a qualidade dos recursos que você dispõe para o projeto, o calibre da equipe e o orçamento reservado. Com a mente fria e os pés no chão, veja o que você poderá fazer em caso ótimo. Dê o desconto para as barreiras e dificuldades que aparecerão (lembre-se dos americanos: “shit happens”) e decida. GES será no mínimo atraente, pois o mundo não é perfeito.