O bug do milênio está vivo

No início desse mês, o New York Times noticiou que os parquímetros de Nova York passaram a rejeitar pagamentos com cartões de crédito e cartões pré-pagos devido a uma falha no software desses equipamentos. O defeito começou a ser percebido em 01/01/2020.

Funcionários do departamento de transporte da cidade tiveram que atualizar cada um dos mais de 14.000 parquímetros da cidade, um a um, num trabalho que durou cerca de uma semana.

Num primeiro momento, a empresa responsável pela manutencão do software comunicou que o sistema estava configurado para não aceitar esse tipo de pagamento a partir de 2020, como se houvesse uma “data final” no sistema. E uma falha na atualização do sistema impediu que essa data fosse corrigida.

Obviamente essa explicação parecia simplista e sem sentido. Niguém faz sistema com uma data para morrer.

À medida em que novos detalhes foram divulgados, concluiu-se que o defeito foi provocado pela solução adotada vinte anos antes para evitar o chamado “bug do milênio”.

Você pode clicar aqui para ler um artigo que escrevi falando sobre o que foi esse “bug”, que também ficou conhecido como Y2K.

A solução definitiva e a solução rápida

Havia duas abordagens principais para evitar o problema da virada de 1999 para 2000: expansão e janelamento.

Na expansão, campos de data que tivessem apenas dois dígitos para representar o ano eram localizados e expandidos para acomodar o século. Essa era considerada a solução definitiva, mas implicava em um número maior de programas impactados, mais esforço para manutenção e teste e, consequentemente, prazos, custos e riscos maiores.

A segunda alternativa, conhecida como janelamento, consistia em estabelecer um ano pivot que seria usado por uma subrotina que decidiria se uma data fazia parte do século XX ou do século XXI.

Assim, por exemplo, se 30 fosse escolhido como pivot, um campo data no formato AAMMDD preenchido com 671217 seria interpretado como 17/12/1967 (porque 67 é maior que o ano pivot, 30). Por outro lado, um campo com 041217 seria interpretado como 17/12/2004 (porque 04 é menor que o ano pivot).

Com essa abordagem, nenhum campo precisava ser expandido e as intervenções aconteciam apenas nos pontos do programa que seriam afetados pelo bug do milênio, basicamente comparações e cálculos envolvendo datas.

O janelamento reduzia a quantidade de programas impactados, os esforços de manutenção e teste, os prazos, os custos e os riscos. Mas tinha um preço: o problema estava sendo postergado para o ano escolhido como pivot. voltando ao exemplo anterior, um campo com 310423 será interpretado como 23/04/1931 daqui a onze anos, o que provavelmente não será a decisão correta.

A longevidade dos sistemas

O que aconteceu com o software do parquímetro de Nova York é que ele vinha trabalhando com ano pivot 20. Logo, datas posteriores ao primeiro dia do ano passaram a ser interpretadas como pertencentes ao ano de 1920, o que provocou todo tipo de problemas.

Vários fatores influenciavam a escolha do ano pivot pelas empresas. Mas a rigor, ainda que todos soubessem que o problema estava apenas sendo postergado, vinte, trinta ou quarenta anos no futuro parecia tempo demais para qualquer sistema legado.

Muitos acreditavam que eles seriam substituídos em algum momento, dada a vertiginosa velocidade com que as coisas mudam na área de TI.

Historicamente, porém, alguns fatos contradizem essa percepção sobre a eterna e inexorável evolução: o COBOL existe há 60 anos, muitos sistemas de missão crítica com 40 anos de idade (ou mais) continuam em pleno funcionamento. Substituí-los em nome da modernidade é caro e arriscado.

O defeito nos parquímetros de Nova York parecem indicar que nos próximos anos haverá, de novo, uma forte demanda por serviços de manutenção e teste de sistemas legados em função das soluções que foram adotadas vinte anos atrás para resolver o bug do milênio.

Desta vez, no entanto, haverá ainda menos gente disponível no mercado para atender a essa demanda.

---