E o COBOL?

O surgimento do COBOL (COmmon Business Oriented Language) confunde-se com a invenção das linguagens de programação de terceira geração (estruturadas) e, sem dúvidas, sua invenção foi um dos projetos mais bem sucedidos do que se tem notícia, liderado por Grace Murray Hopper (e dizem que mulheres não têm talento para desenvolver software...). Desde o início da década de 90, pelo menos, o fim do COBOL é anunciado pelos arautos da inovação. Porém o COBOL, indiferente e imponente (por que não!?) continua na cena. Firme e forte. Liderando com sobras o segmento de ferramenta de desenvolvimento de software para instituições financeiras em geral. Então, o que faz com que este quase “cinqüentão” tenha tanta longevidade?

Primeiramente, consideremos o cenário que impulsionou a criação deste mito: o COBOL foi idealizado e projetado por um comitê (CODASYL) que envolvia fabricantes de computadores e órgãos governamentais americanos. O propósito do comitê era construir uma linguagem para resolver problemas específicos, “orientada a negócios” como o próprio nome diz. Antes de dar início ao seu desenvolvimento, as linhas gerais do projeto foram traçadas e debatidas pelos envolvidos e este assunto foi esgotado. O tempo de desenvolvimento do projeto foi de 6 meses. Em seguida, analisemos os pilares sobre os quais o COBOL foi construído: confiabilidade, desempenho, escalabilidade, estabilidade e proximidade com a linguagem natural (3GL). O que talvez o torne a ferramenta ideal para o desenvolvimento de softwares voltados ao sistema financeiro é sua capacidade de trabalhar com números extremamente grandes e sua alta performance, frente às outras linguagens disponíveis no mercado. Até os dias atuais o COBOL já viu diversas linguagens de sua geração e de gerações mais recentes como BASIC, Clipper, FORTRAN, VB, Delphi, entre outras nascerem, ficarem obsoletas e cair em desuso. É claro que algumas destas visavam outro segmento de software, porém o absolutismo com o qual o COBOL reina por tanto tempo é algo sem precedentes.

Sendo tão aceito pelo mercado e tendo uma história tão consistente, por que seu fim já foi anunciado tantas vezes? Por que há de profissionais capacitados no mercado? Por que as faculdades não ensinam COBOL hoje em dia? Ora, TI é intrinsecamente ligada à inovação e um quase “cinqüentão” cuja última versão (estruturada) foi especificada em 1985 vai contra tudo isso. Os garotos de hoje se negam a aprender uma linguagem que de repente é dominada por seus pais. Uma linguagem em que é preciso “escrever” o programa ao invés de dar meia dúzia de cliques. Que mal há nisso? Pode ser o costume que nossa geração (anos 80) tem de estar mais inteirado a estes aspectos do que seus pais. Pode ser o interesse das empresas capitalistas em criar “novos produtos” (linguagens de programação) e os lançarem no mercado.

Enfim, o fato é que o COBOL está aí. É uma realidade e enganam-se os que prevêem ou planejam sua extinção. Como muitos profissionais relutam em admitir esta realidade, o mercado continua “pagando o preço” da falta de mão de obra sucumbindo à sua mais antiga lei: a da oferta versus procura. Não quero entrar nos aspectos que tangem à metodologia de desenvolvimento, coeficiente de produtividade, ambiente (sistema operacional) e outros. Tudo isso é periférico. O COBOL pode (e deve) ser adaptado às melhores práticas da engenharia de software. Parafraseando um antigo colega: “E viva o COBOL!”.

POG x MDS

Há alguns anos, o movimento pró-metodologias de desenvolvimento de sistemas (MDS) cresceu bastante entre os acadêmicos, porém não parece sensibilizar o mercado e muito menos uma grande fatia de desenvolvedores que ainda insistem praticar a "programação orientada a gambiarras" (POG). Tanto a indústria quanto a academia já comprovaram em diversos estudos e até mesmo na prática que os resultados, quando se utiliza uma MDS no processo de desenvolvimento de sistemas, são infinitamente superiores aos resultados obtidos em um ambiente, digamos, "desordenado". Então, apresento-lhes a grande pergunta: por que os investimentos em metodologias de desenvolvimento de sistemas ainda são relativamente pequenos?

Vamos começar pelo fator que mais interessa às empresas: o fator financeiro. É claro que a utilização de uma MDS tem um custo de implantação, um custo de manutenção e, geralmente, gera um "delay" que afeta diretamente o "time to market" (TTC) dos produtos. Porém, é necessário lembrar que um sistema desenvolvido segundo uma MDS tem um grau de escalabilidade muito superior aos outros e esta característica, muitas vezes, acaba por determinar o tempo de vida útil de um sistema. Por mais que o projeto tenha sido bem feito, um sistema sempre será customizado para adequar-se aos usuários, aos negócios, à legislação ou ao mercado. Sistemas engessados, instáveis e com baixa escalabilidade geralmente são os produtos entregues por equipes de desenvolvimento de sistemas que trabalham desordenadamente.

Nos últimos anos, a academia não mede esforços a fim de comprovar os benefícios agregados pela utilização de uma MDS. O tema é exaustivamente debatido em workshops, simpósios e grupos de discussão. Os analistas de sistemas formados pelas universidades, apesar de conhecerem o assunto ainda são minoria frente os milhares de "coboleiros", "clipeiros" e outros desenvolvedores que não estão dispostos a mudar a forma de fazer sistemas. E talvez aí esteja o maior desafio: MUDAR. O tema "resistência à mudanças" é base para teses e mais teses nas diversas áreas de conhecimento. E mais: é fato. O "modo antigo" de se fazer sistemas, além de gerar sistemas instáveis e pouco escaláveis, gera uma outra figura que é inimiga das empresas: o "dono do sistema". Não é raro nos depararmos com a situação em que apenas uma pessoa (ou grupo) é capaz de manter um determinado sistema (talvez isto explique a "indisposição" em usar uma metodologia). O uso de metodologias inverte os papéis e transfere a propriedade do conhecimento para a organização.

Os profissionais envolvidos neste cenário também poderiam adotar um outro ponto de vista. A consolidação do uso de metodologias pelo mercado, diminuirá consideravelmente a dificuldade de adequação em um novo emprego. Sem procedimentos formais é muito mais difícil encaixar um novo membro na equipe, otimizar o "modus operanti" e até mesmo sair de férias. Isto mesmo: sair de férias. Todos os analistas de sistemas com mais de 5 anos de estrada já devem ter passado pela situação em que não podiam sair de férias porque no período desejável iria acontecer "aquela migração" ou o "fechamento anual". Para não nos tornarmos escravos de nossos empregos, é imperativo que tornemos nosso ambiente de trabalho impessoal.

Enumeremos as vantagens que vimos até o momento:

• Para as empresas: aumento do tempo de vida útil de um sistema, tornando-o mais barato em longo prazo; transfere a propriedade dos conhecimentos para a organização.
• Para os profissionais: impessoalidade; maior abertura para os bons profissionais (acaba com os "donos dos sistemas").
• Para os clientes: sistemas mais estáveis e escaláveis; aumento da qualidade dos sistemas.
  

Vistos todos estes fatores, a pergunta inicial continua sem resposta.

Ah... Já ia esquecendo! Os profissionais tem resistência à mudanças...

Talvez este deva ser o foco das academias e das pessoas que gostariam de ver esta mudança nos rumos da nossa profissão: mostrar para as pessoas que mudar não é ruim, e que, neste caso, a mudança tem tudo para ser positiva para todos os envolvidos. Como em todas as quebras de paradigma, o desafio não é fácil.