[ originalmente publicado na revista digital NO., em 16.Nov.2001 ]
Muitas das coisas aparentemente mais simples do mundo são, de fato, complexas de descrever, explicar e, claro, entender. Programas de computador são uma delas. Os primeiros computadores não eram programáveis como as máquinas que usamos hoje em quase todo canto. Suas rotinas de funcionamento eram estabelecidas por conexões físicas, feitas com fios que interligavam os componentes através dos quais os dados que estavam sendo “processados” deveriam passar até que, eventualmente, algum resultado fosse apresentado ao usuário. Estamos falando da Idade da Pedra Computacional, já que o primeiro computador que podia armazenar um programa qualquer foi construído na University of Manchester em 1948. O conceito de “computador de programa armazenado” está presente em artigos escritos por Konrad Zuse na década de 30 e foi formalizado pela primeira vez em 1945, num texto de John von Neumann, que trabalhava em conjunto com John Mauchly, J. Presper Eckert e Herman Goldstine na University of Pennsylvania.
A idéia de armazenar programas juntamente com dados, na memória de computadores tem, então, pouco mais de cinqüenta anos. Neste meio século, saímos do nada para construir programas que têm muitas dezenas de milhões de linhas de código, algo quase fora da imaginação e controle de qualquer time, por maior, mais capaz, dedicado e sortudo que seja. Não é à toa que muitos dos programas que fazem parte das nossas vidas diárias têm um, dois, três (ou muito mais) defeitos (erros de programação que causam falhas de operação do ponto de vista do usuário final) para cada mil linhas de código, o que explica todas as panes e desastres que eu e você estamos acostumados a enfrentar no banco, nos supermercados, nos serviços de governo, nas transações da web. Pode ser melhor? Pode, muito melhor.
Mas para tal temos que entender mais apropriadamente o que é software. Claro que não vai ser neste artigo aqui que iremos estabelecer os fundamentos filosóficos da matéria, mas é possível fazer uma comparação muito prática e apropriada para o caso. Qualquer programa pode, para nossa análise, ser visto como um texto escrito em uma linguagem. Uma linguagem de programação, como qualquer língua, como o português, é definida em termos dos caracteres (letras, números e símbolos) que podem ser usados para formar palavras, as regras de formação das palavras, as regras de criação de sentenças a partir de palavras e um outro conjunto de regulamentos sobre como articular sentenças em textos maiores e inteligíveis. Considere o texto que você está lendo agora: se eu não tivesse usado as boas maneiras da língua portuguesa enquanto o escrevia, talvez não fosse possível entender partes dele ou até o texto como um todo. Tente embaralhar os parágrafos, as sentenças ou as palavras que ele vai ficar cada vez mais difícil de entender.
A diferença, em um programa de computador, é que as regras são mais estritas, já que o programa vai ser interpretado por uma máquina bem mais limitada do que um ser humano e, por isto mesmo, desprovida do que costumamos chamar de “bom senso”. Se, em algum lugar do programa que está tratando um depósito na sua conta, houver uma instrução mandando remeter 10% do valor para uma conta em Jersey, isso será feito sem pestanejar. Mesmo que a conta seja de uma outra pessoa (que negue, por acaso, ter qualquer relação com a matéria)… Este defeito pode ser de boa fé (o programador errou a codificação e tal não foi identificado nos testes pelos quais o programa deveria ter passado) ou de má fé, no caso em que, deliberadamente, alguém tenha inserido linhas de código que desviam dinheiro para paraísos fiscais. O primeiro é um puro e simples defeito, o segundo é um crime.
Deixando os crimes, neste artigo, para lá, por que os programas têm tantos defeitos? Philip Armour (na coluna “The Business of Software”) desenvolveu, em mais de um artigo, dois conceitos fundamentais para entender software (e seus defeitos). O primeiro é que software é um meio de armazenamento, e não um produto em si. Software seria, na verdade, o quinto meio, do ponto de vista da seqüência histórica de seu aparecimento no planeta, a servir para guardar conhecimento. Os quatro primeiros seriam DNA (há bilhões de anos atrás), cérebros (há uns dois e meio milhões de anos), hardware (de todo tipo, começando por ferramentas, que Peter Drucker chama de conhecimento sólido, há uns quarenta mil anos) e livros. Os livros datam de sete mil antes de Cristo, mas só quando foram reinventados, pela via da prensa de tipos móveis de Gutemberg, foi que seu impacto se fez sentir em todo planeta, há uns 550 anos. Bom… software, então, é o primeiro meio de armazenamento a aparecer em mais de meio milênio. E o que armazenamos em software?
Conhecimento é a resposta. Os programas que foram e estão sendo escritos no mundo servem para armazenar conhecimento sobre todo tipo de coisa, concreta ou abstrata, que existe na face da Terra (e fora dela). Um sistema de informação de um banco é, em verdade, um modelo abstrato do mesmo, programado e executando em um monte de computadores, para nos dar a impressão (bastante real, por sinal), de que o sistema é o banco. Um sistema informatizado de controle de tráfego aéreo simula os aviões e o espaço aéreo nas unidades de processamento, memória, entrada e saída dos computadores e mantém tal simulação a par e passo com a vida (em tempo) real lá fora, comandando os aviões a se afastarem uns dos outros, a subir, descer… fazendo funcionar o tráfego aéreo. Trens, motores, freios, fornos de micro-ondas… todos os programas neles embutidos são conhecimento codificado em alguma linguagem, simulando alguma parte do mundo real, ao mesmo tempo em que comandam alguma interferência na mesma, de forma a realizar algum processo real. Desde fazer pipoca até evitar o travamento de rodas.
E os defeitos? Ah, sim, os defeitos. Assumindo que não há má fé e que os engenheiros e outras pessoas envolvidas no desenvolvimento do sistema dominam suas profissões a ponto de não cometer erros técnicos (o que quase nunca é o caso, em se tratando de humanos), os defeitos, em sua maioria, vêm da nossa incapacidade em adquirir conhecimento sobre o que estamos tentado armazenar no software. Armour estabelece cinco ordens de ignorância que afetam os mortais comuns como nós. Eu tenho zero ordens de ignorância (0OI) sobre alguma coisa quando eu entendo da mesma e posso demonstrar minha falta de ignorância sobre o assunto de alguma forma tangível… 0OI é a falta de ignorância. Falta de conhecimento, por sua vez, ou uma ordem de ignorância (1OI), se dá quando eu não sei alguma coisa e posso identificar o fato prontamente. 1OI é a ignorância básica, benigna. Começa a ficar complicado quando me falta desconfiômetro, quando tenho 2OI: aí, eu não sei que não sei alguma coisa. Não só eu sou ignorante sobre algo (por exemplo, que eu tenho 1OI no assunto) mas eu nem desconfio deste fato. Pessoas com 2OI costumam “saber” muito… procure ao seu redor.
Danado mesmo é quando chego em três ordens de ignorância (3OI). Aí, sofro de falta de processo: 3OI siginifica que não conheço uma forma eficiente para descobrir que não sei que não sei alguma coisa. Enquanto as pessoas que sofrem de 2OI perturbam o ambiente e podem ser de difícil lida, quem sofre de 3OI é definitivamente perigoso para a instituição em que se encontra. Finalmente, o caos, a meta-ignorância (4OI): alguém tem 4OI quando eu nem sabe que existem Cinco Ordens de Ignorância, pelo que, leitor, acabamos de passar. Estamos em algum lugar entre zero e três…
E o que isto tem a ver com defeitos em software? Tudo. Como software é conhecimento codificado, na maioria das vezes sobre sistemas, processos, serviços e instituições de grande complexidade (inclusive porque têm clientes humanos!) ele só funciona corretamente e realizando tudo (e só!) o que teria que fazer quando o processo de descoberta e codificação de conhecimento que é, de fato, o desenvolvimento de sistemas de informação é realizado por gente que combina zero e uma ordens de ignorância. Não só quando se trata do objeto da codificação, mas da técnica sendo usada para tal. Ou a pessoa sabe e o demonstra na prática (0OI), ou não sabe, é capaz de anunciá-lo aos quatro ventos e pedir ajuda (1OI) a algum especialista de verdade, outro alguém com 0OI no assunto… Na prática, porém, muita gente “acha que sabe” (não sabe que não sabe, e tem 2OI) e outros, ainda, são mais perigosos, pois nunca nem vão descobrir (3OI) que há coisas que não sabem que não sabem. À frente da tela, nós, lidando com os defeitos, ainda por muito tempo. Pelo menos, agora, sabemos que a culpa, em algum lugar, é de gente com mais de uma ordem de ignorância.
[uma observação de quase 20 anos depois, sobre uma imagem de 15 anos depois do original]
Em 2015, discutindo inovação em educação, que supostamente é um sistema social para diminuição da ignorância coletiva [neste link], reescrevi as 5 ordens de ignorância de Armour em ~6, porque isso tornava mais fácil a explicação de certas facetas do sistema educacional… que em muitas instâncias leva as pessoas a saberem as coisas em tese, sem necessariamente saber fazer. Este é o caso, infelizmente, de boa parte do sistema educacional brasileiro, em especial no ensino fundamental e médio, neste último em especial, que quase nunca prepara seus aprendizes para qualquer coisa além do vestibular.
