A versão em inglês desta frase é muito conhecida por quem usa programas de computador: “is it a bug or a feature?”. Ela roda pela área de informática há muito tempo. Pode causar algum espanto o uso da palavra “bug” (inseto) para indicar um defeito. Mas, na computação, há uma base histórica e anedótica para isso. Reza a lenda (e há documentação) que, quando os computadores ainda usavam válvulas eletrônicas e relés eletromecânicos, houve certo dia um mal funcionamento inesperado em uma máquina. Após buscar a causa do problema, verificou-se que um inseto se introduzira entre as lâminas de um relé do computador, causando o mau contato deletério.
O primeiro “bug” foi, assim, literal e um evento mecânico. Com a crescente complexidade da programação, além de eventuais erros físicos em equipamentos, erros de programação passaram a ser muito frequentes. Um programa complexo é de difícil depuração. Mesmo com todo o cuidado do programador, é provável que erros e incoerências tenham escapado. Por extensão do que ocorreu com o relé e o inseto, os erros de programação passaram a ser chamados “bugs”, e o processo de examinar cuidadosamente o programa para livrá-lo dos eventuais erros “debugging” – ou seja, “desinsetização”.
Além dos diversos tipo de erros que podem estar ocultos num programa, ele pode apresentar características inesperadas, introduzidas a propósito no programa, ou, simplesmente, decorrência de alguma inconsistência ou de um “bug”. Um dito irônico afirma que, uma vez detectada a existência de um erro, se ele for convenientemente documentado no sistema, evoluirá e passará a ser considerado uma “característica”. No processador M6800 da Motorola havia uma instrução de máquina não documentada e que, se executada, faria o processador simplesmente desistir de prosseguir e passar a se comportar como um simples contador. O pessoal havia a denominado como “pare e pegue fogo” (HCF,“halt and catch fire” em inglês). Provavelmente esqueceram-se de removê-la após o fim da fase de projeto.
Enfrentamos esse tipo de problema em situações as mais diferentes do nosso dia a dia. Se algo é reconhecido como insuficiente ou gerador de risco, pode-se tentar consertá-lo ou, saindo pela tangente, avisar os usuários que “não é bom” usar determinado recurso, porque pode redundar em dor de cabeça. Nos mapas antigos, por exemplo, as regiões desconhecidas e inexploradas eram marcadas como sendo áreas em que “há dragões”, ou seja, melhor seria não ir para aqueles lados: um erro transformado em característica. Quem quiser prosseguir, que o faça por sua própria conta e risco.
O risco, aliás, é sempre inerente à pesquisa – não se faz investigação sem correr algum risco, mas há que manter em mente a necessidade de não criar riscos adicionais pela simples dificuldade em depurar o que fizemos, ou de não gerar situações que saiam do controle.
O simples ato de tentar prever tendências e resultados, mesmo que executado com plena isenção, pode envolver metodologias e amostras nem sempre controláveis nas condições disponíveis.
Mas, como somos todos humanos e falíveis, sempre podemos lançar mão de alguma explicação posterior, que transforme o que pareceria uma falha metodológica ou de aplicação, numa interessante “característica inesperada”. Mas a quem sofreu as consequências, não alivia saber se elas foram devidas a um “bug” ou a uma “feature”.
