Será que já é hora de aprender COBOL?

Uma sensação de desconforto começa a tomar conta de algumas das maiores instalações de TI do planeta. Onde estão os novos profissionais de mainframe que vão substituir aqueles que estão se aposentando?

“O futuro é o Clipper”

Quando me matriculei no primeiro curso de COBOL, lá no início dos anos 1980, um amigo também interessado em computação me avisou:

– Cara, o COBOL tá morrendo! O futuro é o Clipper!

Para quem chegou a menos tempo, o Clipper era uma linguagem desenvolvida pela Nantucket no início dos anos 1980 e que permitia o desenvolvimento rápido de pequenas aplicações para MS-DOS. Demorou para fazer uma transição eficiente para a plataforma Windows e foi atropelada por Visual Basic, Delphi e Powerbuilder em meados dos anos 1990.

De lá para cá trabalhei (e continuo trabalhando) com COBOL em bancos, seguradoras, empresas de telefonia, redes de varejo e institutos de previdência.

Já dei manutenção em sistemas mais velhos que eu. Já reconstruí (em COBOL) programas que foram codificados antes do “advento” da programação estruturada. Participei de alguns projetos que tentaram reescrever alguns desses sistemas em outras plataformas e fracassaram num pesadelo de restrições técnicas, falta de performance e complexidade de governança… Também participei de alguns projetos que jogaram fora o sistema antigo e reescreveram tudo… em COBOL.

Por que o COBOL se recusa a morrer?

Linguagens de programação às vezes se parecem com jogadores de futebol. Têm um desenvolvimento rápido quando saem das divisões de base, chegam ao auge no mercado profissional e depois começam a perder desempenho. Sofrem pressão de “jogadores mais jovens” que estão despontando, vão para o banco de reserva e terminam num time da segunda divisão do Acre, quando caem no esquecimento da mídia.

O COBOL, estranhamente, parece seguir outra trajetória. Uma pesquisa encomendada pela Micro Focus e realizada pela Harris Interactive mostrou que o COBOL está presente em 70% das grandes empresas, 90% de todas as transações financeiras (incluindo operações em caixas eletrônicos), 30 bilhões de transações eletrônicas por dia, 200 bilhões de linhas de código em processamento…

Voltando à nossa analogia esportiva, é como se um jogador de quase 60 anos ainda estivesse jogando no Manchester, no Barcelona ou no PSG.

Uma das muitas explicações para esse fenômeno (que a cada ano parece incomodar mais e mais as publicações especializadas) está no fato de que o COBOL ainda está no centro nervoso das grandes empresas. Muitos sistemas departamentais migraram do mainframe para plataformas distribuídas. Muitas aplicações novas surgiram, em outras plataformas. Mas o COBOL permaneceu no coração dos sistemas de missão crítica.

E substituir sistemas críticos, com dezenas de milhares de programas, milhares de funções e milhões de linhas de código, não é um projeto simples nem seguro. Em outras palavras, o investimento necessário para fazer essa substituição não teria um ROI que o justificasse.

Ficou em dúvida se o ROI realmente não justifica? Vejamos de forma bem simplista o que significa substituir um sistema crítico:

• Contratar uma nova equipe para levantar requisitos funcionais e não funcionais, desenhar, construir, testar e homologar o novo sistema (a equipe antiga precisa dar manutenção no sistema anterior)
• Disponibilizar infraestrutura (servidores, instalações, energia, integração…) e suporte (administradores, operadores…) para desenvolvimento, teste e implantação do novo sistema
• Redefinir procedimentos operacionais (políticas de segurança, backup, auditoria, produção, sustentação…)
• Treinar usuários
• Planejar um roll-out gradual para migrar clientes e operações de um sistema para o outro (ninguém vai querer virar a chave de uma vez)
• Congelar (ou duplicar) todas as manutenções evolutivas (inclusive necessidades de negócio) enquanto durar o roll-out

Anos de CapEx pesado investido num projeto que só seria aprovado se prometesse um ganho que pagasse todo o investimento no médio prazo, cinco anos no máximo.

“Vender” um projeto desses não seria fácil: dizer que o PHP e Ruby são mais modernos e mais legais não é suficiente para os sponsors. Prometer uma eventual (mas não garantida) queda no TCO deixaria muita gente na dúvida. E na dúvida, deixa como está.

A eutanásia esteve próxima

Se houve um momento na história da computação em que o COBOL teve sua sobrevida discutida, esse momento sem dúvida foi o bug do milênio.

Naqueles dois ou três anos que antecederam o ano 2000, muitas das grandes empresas usuárias do COBOL cogitaram seriamente a possibilidade de substituí-lo. Afinal, se havia necessidade de varrer todos os programas fonte em busca de anos com dois dígitos, alterar todos os programas, testar, homologar e dar suporte pós-implantação, por que simplesmente não jogá-los fora e escrever tudo de novo? Ou comprar um pacote, se houvesse um?

Muitas propostas comerciais milionárias foram apresentadas nesse período. Mas o que fechou a decisão foi o preço e o retorno. Renovar o código para trabalhar com ano de quatro dígitos não foi barato. Mas reescrever tudo (ou preencher os gaps de um pacote) seria mais caro.

O bug do milênio serviu não só para mostrar a inviabilidade econômica de uma migração de sistemas em massa. Naquele momento acendeu-se uma luz amarela, inicialmente pequena, mas que vem ficando mais intensa a cada ano: onde estão os “novos” programadores COBOL?

Quem vem nos substituir?

Em 1998/1999 não havia profissionais suficientes no mercado mundial para atender à demanda por COBOL (e NATURAL, PL/I, Assembler, Easytrieve…) para projetos do bug do milênio. Conheço muita gente daqui que foi contratada em Portugal, nos Estados Unidos, na Austrália, na França… E vi muita empresa brasileira tendo que encontrar e oferecer emprego para profissionais já aposentados ou que haviam mudado de profissão. O valor/hora oferecido valia a pena tentar de novo.

Nunca se pagou tão caro. Nunca se produziu tão pouco. Vi antigos analistas se esforçando para voltar à ativa. Só que eles não sabiam usar um mouse… nem o Windows, nem o Office, nem nenhuma outra ferramenta de apoio tão comuns naquele momento… Deixaram seus empregos e seus terminais 3278 para trás e quando voltaram se viram na sala de comando da USS Enterprise com o Capitão Kirk falando uma língua que eles não entendiam…

O ano 2000 passou. Os sistemas foram adaptados e, por isso, nenhuma das desgraças anunciadas nos anos anteriores se confirmou. A demanda pelos programadores COBOL voltou ao normal e o tempo foi passando.

Em 2013, outra pesquisa global encomendada pela Micro Focus mostrou que 73% das universidades com cursos de computação não tinham mais nenhuma disciplina específica sobre o COBOL.

Em 2014, uma pesquisa da Bloomberg mostrou que mais da metade dos programadores COBOL tinham mais de 50 anos e estavam próximos da aposentadoria.

Traçando as duas retas é fácil ver onde elas vão se encontrar no futuro próximo: vai faltar gente no mercado, de novo.

Essa já é uma preocupação, por exemplo, da Office of Personnel Management (OPM), agência do governo americano responsável pela gestão da mão de obra civil no governo federal. Em março de 2014, a OPM divulgou um relatório chamado “Strategic Information Technology Plan“, onde sinalizava um crescimento de 10% a 15% no salário dos programadores COBOL, uma vez que “os profissionais com experiência na linguagem estão se aposentando e não podem ser substituídos com facilidade“. A agência responsável pela seguridade social nos EUA, por exemplo, declara ter 60 milhões de linhas de código em sistemas críticos em produção.

Em 2012, a Computerworld publicou um artigo especificamente sobre a crescente falta de profissionais qualificados em COBOL e o quanto essa preocupação vinha aumentando entre os CIOs.

Conclusão

Toda vez que leio um daqueles artigos que falam “nas 5 linguagens de programação que vão bombar no ano que vem”, eu me lembro do meu velho amigo de colégio garantindo que o futuro era o Clipper.

Eu torço para que o Java – linguagem que por acaso gosto muito – tenha uma vida tão longa e próspera quanto o COBOL. Acho mesmo que o PHP é uma mão na roda pra quem gosta de client-side e front-end…

Mas se um dos meus filhos, um dia, demonstrar algum interesse por programação, vou começar falando assim:

– Um programa tem quatro divisões…

---