Esta história é uma versão editada de uma mensagem que postei recentemente no fórum Multics no LinkedIn.
Ter suas mudanças "ao vivo" muito rapidamente pode ser um poderoso incentivo. Esta é a história sobre o primeiro bug que introduzi no Multics, que foi um grande sistema operacional que estava sendo criado no MIT no final dos anos 60 e início dos anos 70.
Eu era um jovem caloiro do MIT que tinha sido aceito no projeto Multics. Eu me ofereci para adicionar um recurso ao comando dprint ("daemon print") que enfileirava pedidos para que o daemon da impressora de linha fosse processado. Um dos gerentes me pediu para registrar o número de cópias no pedido, em vez de adicionar N pedidos à fila de espera. Esta mudança resolveria uma condição de corrida envolvendo a exclusão de pedidos de impressão concluídos. Eu fiz as mudanças e as testei para minha satisfação.
Minhas mudanças foram logo instaladas e fiquei entusiasmado por poder melhorar o sistema. Mas minha emoção foi curta, pois logo respondi ao telefone do meu escritório e me vi escutando um usuário irritado reclamando que eu havia quebrado seu programa. Voltei e vi que não havia notado, ou testado, o ponto de entrada da sub-rotina no mesmo arquivo fonte. Com certeza, eu o havia quebrado. Eu o consertei e a vida continuou. Mas eu nunca esqueci aquele telefonema. Ainda não sou perfeito, mas aquele eco irado de voz dentro da minha cabeça me salvou de cometer muitos erros semelhantes e descuidados ao longo dos anos desde então.
O aforismo que cunhei deste caso é "Código não testado não funciona".
Teste seu código. Encontre seus próprios bugs; não faça com que outras pessoas os encontrem. Evite a voz irada!
Empresa