Vivemos lendo que a origem do bug do ano 2000 foi a necessidade de economizar recursos como memória e disco, que, tempos atrás, eram caros e limitados. Na verdade, essa argumentação não resiste a uma análise mais detida e serve apenas para camuflar o real motivo: a imprevidência e/ou o desleixo puro e simples dos programadores.
Para começar, é difícil acreditar que o espaço obtido com a supressão de dois dígitos faça uma diferença efetiva, especialmente se comparado àquele ocupado por strings longas como nomes e endereços, onipresentes em bancos de dados por toda parte. Remover meia dúzia de dígitos em registros de 200 ou mais bytes é uma técnica de eficácia discutível no que se refere ao objetivo de economizar espaço.
Isso não quer dizer que não haja casos em que o espaço - em memória ou em disco - seja crítico. Em geral, a maneira de se enfrentar esse tipo de desafio é escrevendo programas pequenos e eficientes, quase sempre em Assembly, ou, se isso não for possível, em alguma linguagem que gere um código enxuto e controlável, como Algol ou C. Além disso, é uma boa idéia restringir o tamanho de todos os dados (não apenas anos) e recorrer a algum tipo de compressão de dados. Mas o fato é que essas características, comuns em software de baixo nível, não costumam ser encontradas em aplicativos.
Mesmo uma providência simples como a diminuição do número de bits usados para representar cada caractere foi poucas vezes tentada. A quase totalidade dos sistemas utiliza oito bits - EBCDIC nos mainframes IBM, ASCII estendido nos PCs - quando seis seriam suficientes para representar todas as letras (quem não tem espaço não precisa de minúsculas), algarismos e símbolos gráficos. É simples escrever uma função para converter entre oito e seis bits, mas, excetuando-se casos específicos, não há quem tenha essa preocupação.
Indo mais longe, se espaço fosse mesmo importante, ninguém usaria uma linguagem como Cobol, que estimula fortemente o desperdício. No Cobol não há o conceito de escopo nem de alocação dinâmica: as variáveis são sempre estáticas e devem estar todas presentes em memória simultaneamente. Além disso, cada dado a ser mantido exige, tipicamente, a manipulação de pelo menos duas ou três variáveis (uma para guardar o dado propriamente dito, outra para apresentá-lo na tela, outra para efetuar operações específicas etc.), o que piora ainda mais o panorama. No Cobol, por default, variáveis numéricas são armazenadas como caracteres ASCII; para representá-las como valores numéricos, em hexadecimal, o programador precisa declarar isso expressamente. Muitos programadores não o fazem e o resultado é que um ano de dois dígitos - que, representado em hexa, cabe em um byte - acaba ocupando dois bytes, exatamente o mesmo tamanho requerido por um ano de quatro dígitos armazenado de forma adequada.
Ironicamente, o Cobol é até hoje, como se sabe, a linguagem mais popular que existe para a construção de aplicativos e aquela que, por não oferecer um tipo de dados ‘‘data’’, mais apresenta obstáculos para a compatibilização com o ano 2000.
O custo de memória e disco, que já não é proibitivo há duas décadas, caiu a níveis risíveis nos anos 90, mas nem por isso os programadores passaram a utilizar anos de quatro dígitos: muitos dos programas defeituosos foram escritos há menos de três anos! Desde a invenção do computador, os programadores têm dedicado dois dígitos aos anos não por economia, mas porque é assim que todos nos referimos a eles em cheques, recibos e memorandos.
No caso dos programadores da década de 60, que não imaginavam que seus programas permaneceriam em produção por tanto tempo, é uma desatenção desculpável. No caso dos programadores de anteontem, a falha pode ser considerada desleixo ou negligência. Mas o fato é que, em maior ou menor grau, é tudo imprevidência mesmo.

mockup