De onde vêm os bugs?

Gabriel Ullmann
5 min readApr 18, 2020

--

Raven and The First Men, Bill Reid, fotografado no Museu de Antropolgia da UBC, fev. 2018, arquivo pessoal.

De onde viemos? A escultura “Raven and The First Men”, do artista canadense Bill Reid, explica essa questão segundo as tradições do povo indígena Haida. Reza a lenda que um corvo teria encontrado os primeiros seres humanos em uma concha na praia. Milênios depois, embora as indagações existenciais ainda nos atormentem, dedicamos a maior parte do nosso tempo a questões mais utilitárias, tais como: por que as coisas não funcionam? No mundo em que vivemos, essas “coisas” frequentemente são software e esses problemas são o que chamamos de bugs.

Bugs tem várias causas e origens, mas acredito que podemos informalmente dividi-los em 2 grupos: os prováveis e os improváveis. Bugs improváveis são aqueles que ocorrem em casos específicos, por mais que o software passe por um processo de testes adequado. Por exemplo, quando cria-se uma aplicação web, é difícil prever como as páginas vão se comportar em dezenas de combinações de navegadores, sistemas operacionais e dispositivos diferentes. Por mais que possamos garantir que a aplicação vai funcionar corretamente nas plataformas mais populares, é difícil estender essa garantia a 100% dos casos. Ou, parafraseando o cientista holandês Edsger Djikstra:

Os testes de um programa podem ser utilizados para constatar a presença de bugs, mas não sua ausência.

Contudo, há bugs que podem ser previstos e evitados, seja durante a fase de planejamento do projeto, seja mais adiante, durante as contínuas iterações para execução, teste e melhoria. Creio que esses são os que mais “doem no coração” dos programadores, pois muitas vezes eles estão evidentes mas, por não interferirem em funcionalidades fundamentais do software, acabam sendo deixados de lado por falta de tempo para análise e resolução.

Essa falta de tempo é, em parte, compreensível. A indústria de tecnologia tem produtos em grande demanda atualmente, e portanto é natural que as empresas da área estejam sempre tentando entregar projetos de forma ágil, tanto para dar conta dessa demanda quanto para se destacar da concorrência. Porém, o problema é quando essa “agilidade” se transforma em “pressa”, pois isso leva projetos a serem conduzidos de forma desorganizada, sobrecarregando equipes e por vezes tornando o software final muito menos “polido” e portanto, mais propenso aos bugs.

Mas afinal, existe alguma maneira de encontrar equilíbrio entre agilidade e qualidade? É possível fazer software com poucos bugs de forma rápida? Há mais de um ponto de vista quanto a melhor abordagem nesse caso. Comecemos pelo ponto de vista do desenvolvedor americano Al Sweigert em seu livro “Automatize Tarefas Maçantes com Python”:

Programar é uma atividade criativa (…). Como pintar em uma tela em branco, criar software apresenta várias limitações mas infinitas possibilidades.

O ser humano cria coisas desde o início dos tempos, sejam coisas simples e consumíveis (como um bolo) ou coisas grandiosas, feitas para durar milênios (como as Pirâmides do Egito). Softwares se encaixam em algum lugar entre essas duas definições. Enquanto alguns logo tornam-se obsoletos, outros permanecem úteis por décadas, como no caso do sistema operacional BSD, “avô” das distribuições Linux que utilizamos hoje em dia e que começou a ser desenvolvido em 1969.

Mas o que torna um software (ou qualquer produto criativo) tão durável? Segundo Bill Reid a resposta não está no produto em si, mas na forma em como o produzimos:

Uma qualidade básica une todas as obras da humanidade e fala conosco em vozes humanas, reconhecíveis através das barreiras do tempo, cultura e espaço: a simples qualidade de ser bem feito.

Em resumo: coisas duráveis são bem feitas. Contudo, a forma rápida, superficial e constantemente mutável de nossos projetos muitas vezes nos impede de criar algo de alta qualidade. É nesse contexto que os bugs aparecem, e a partir disso podemos tirar uma conclusão: grande parte dos softwares não é feito para durar, mesmo quando queremos que essa durabilidade exista.

Mas será que a solução para produzir software melhor seja apenas diminuir a velocidade de produção e focar mais na qualidade? Qual é a relação entre esses dois fatores? O artista japonês Takashi Murakami compartilha em sua exposição “The Octopus Eats Its Own Leg” — a qual tive o privilégio de visitar em 2018 no Canadá — um pouco sobre como essa dualidade se reflete na criação de suas obras:

Estou escrevendo estas palavras para me desculpar, pois não consegui terminar minhas pinturas. No fim das contas, sem um prazo sou incapaz de criar a situação de urgência, de vida ou morte, da qual preciso para ser produtivo […]. É [nessas situações] que ideias brilhantes costumam aparecer para mim, seja através da secreção de dopamina ou endorfina, seja pelas sinapses que repentinamente se conectam. Essas ideias geralmente são surpreendentes, bizarras e fora do normal, coisas nas quais eu nunca teria pensado quando comecei a pintar. Elas só vem até mim, contudo, no último minuto.

Pintura mostrando caveiras de diferentes formatos e texturas.
Lion Occupying the Throne in My Heart, Takashi Murakami, Artsy

Ou seja: a urgência também pode ser, em alguns casos, nosso combustível criativo. Ao longo da história da humanidade, muitas inovações surgiram pela pressão da necessidade, seja de um indivíduo ou de uma sociedade inteira. O mesmo continua ocorrendo hoje em dia com o mercado de software, que visa atender as necessidades imediatas de um público mas também desenvolver uma visão de futuro, de forma a criar um produto que sirva hoje para servir sempre.

Então, voltando à pergunta feita anteriormente: é possível fazer software com poucos bugs de forma rápida? Sim. Entretanto, é óbvio que o caminho não é fácil. Corremos o risco de pecar por excesso de detalhismo algumas vezes, ou por falta de diligência em outras. Mas no fim das contas, a melhor forma de aprender é fazendo. É preciso aprender com os acertos e erros de cada projeto e tomar ações para buscar um processo equilibrado, que não sobrecarrega seus participantes nem deixa de lado os prazos e a qualidade.

Fontes:

--

--

Gabriel Ullmann

Pesquisador de Engenharia de Software, sempre garimpando por coisas interessantes no código de video games e apps em geral. Atualmente em Montreal, Canada.