Bugs

Por Cesar Brod

Data de Publicação: 11 de Fevereiro de 2008

O termo é antigo e há polêmicas sobre sua origem. A Wikipedia apresenta a história do fonógrafo bichado de Thomas Edison, da baratinha que Grace Hopper encontrou nos contatos de um relê do Mark II e das mariposas e outros bichos atraídos pelas luzes e o quentinho das válvulas do Eniac. Eu fico pensando em bugs nas vezes em que viajo e vários insetos esborracham-se no parabrisas do meu carro. Isso me faz concluir que o bug mesmo, o real problema, só quem é capaz de detectar é o usuário final de um produto. O carro é uma boa analogia. Por mais perfeita que seja sua engenharia, os bugs estarão presentes e afetarão diretamente o usuário.

Em seu livro, Hackers & Painters, Paul Graham diz que as empresas de software são acusadas de permitir que os próprios usuários apontem os problemas em seus programas. "É justamente isso que eu defendo!", completa o autor. De certa forma, eu também! Paul é uma baita referência no mundo da internet. É dele e de Robert Morris a primeira aplicação para a web, a Viaweb, que também virou o nome da empresa deles, comprada em 1998 pelo Yahoo!. Viaweb é, ainda, a alma do Yahoo! Merchant. Mesmo defendendo que o usuários é quem deve descobrir problemas, Paul aponta que a quase totalidade dos usuários da Viaweb jamais encontrou problema algum. Isto porque, uma vez que um usuário encontrasse um problema, o mesmo era sanado antes dos demais o experimentarem. Paul conta que, um erro que acabasse sendo crítico o suficiente para levar o nome da empresa a um portal de notícias na internet seria o suficiente para decretar o fim de seus negócios.

Metodologias ágeis, como o Extreme Programming, defendem que, ao encontrarmos um problema, antes de desenvolver uma solução devemos criar um teste que detecte tal problema. Indo além, a metodologia fala de testes de conceito, pequenas soluções às quais os usuários podem ser expostos prematuramente. Essa interação entre o usuário que encontra o erro, a criação de uma rotina que teste pela ocorrência de tal erro (impedindo sua proliferação) e a solução do problema é que refinam um bom programa. Aliás, isto aplica-se ao desenvolvimento de qualquer produto. No caso de produtos para um público contido, grupos de usuários de teste (os mais críticos) podem ser utilizados. Em casos de aplicações para um público grande e generalizado, muitas vezes, a melhor solução é colocar mesmo a cara a tapa, na web, e observar o comportamento dos usuários. Salvas as devidas proporções, claro! Uma rede de relacionamentos é bem diferente de um ambiente de transações financeiras. Mas ter o usuário como aliado na detecção de problemas é fundamental para o sucesso de qualquer projeto.

Outra coisa a ser entendida é que a máxima "O cliente tem sempre razão" tem que ser respeitada. Um problema é o que o cliente define como problema e ponto final. A solução do problema, porém, pode não estar exatamente no código de um programa ou em sua engenharia. Sua origem pode estar no entendimento do que o sistema deve fazer, tanto do lado do usuário quanto do lado de quem desenvolveu o sistema. Por isso, quanto mais cedo no projeto o usuário estiver envolvido, melhor. Idealmente, o usuário tem que participar da definição do próprio sistema. Sobre isso já comentei na minha série de artigos sobre Scrum.

A leitura do livro e dos artigos de Paul Graham é, em minha opinião, essencial para todos os envolvidos em projetos de software, mas obrigatória para gestores de empresas fornecedoras de tecnologia. Comece pelo The Other Road Ahead, ele será suficiente para chamar a sua atenção para os demais.