Esta história é uma versão editada de uma mensagem que publiquei recentemente no fórum Multics no LinkedIn.
Ter suas alterações “entrando em operação” muito rapidamente pode ser um incentivo poderoso. Esta é a história sobre o primeiro bug que introduzi no Multics, que era um importante sistema operacional que estava sendo criado no MIT no final da década de 1960 e início da década de 1970.
Eu era um jovem calouro do MIT que havia sido aceito no projeto Multics. Eu me ofereci para adicionar um recurso ao comando dprint (“daemon print”) que enfileirava as solicitações para o daemon da impressora de linha processar. Um dos gerentes me pediu para registrar o número de cópias na solicitação, em vez de adicionar N solicitações à fila. Essa alteração resolveria uma condição de corrida envolvendo a exclusão de solicitações de impressão concluídas. Fiz as alterações e as testei até ficar satisfeito.
Minhas alterações foram rapidamente instaladas e fiquei entusiasmado por poder melhorar o sistema. Mas meu entusiasmo durou pouco, pois logo atendi o telefone do escritório e me vi ouvindo um usuário irritado reclamando que eu havia danificado seu programa. Voltei e vi que não havia percebido, nem testado, o ponto de entrada da sub-rotina no mesmo arquivo fonte. Com certeza, eu o havia danificado. Consertei e a vida continuou. Mas nunca esqueci aquele telefonema. Ainda não sou perfeito, mas aquela voz irritada ecoando na minha cabeça me salvou de cometer muitos erros semelhantes e descuidados ao longo dos anos desde então.
O aforismo que criei a partir deste caso é: “Código não testado não funciona”.
Teste seu código. Encontre seus próprios erros; não deixe que outras pessoas os encontrem. Evite vozes irritadas!