O programador invisível

Texto escrito em 2014

Quais os instrumentos que você usa para perceber o mercado de software? Revistas? Conferências como QCon, DevDay, etc? Blogs como este e tantos outros? Já parou para pensar que possívelmente a maior parte do mercado de software lhe seja completamente invisível? Vou te contar uma coisa: ele é, gera um valor muito maior do que imaginamos, está na nossa frente e simplesmente não conseguimos enxergá-lo. Hoje vou falar sobre os programadores invisíveis: aqueles que geram muito mais valor que todos nós juntos e não se preocupam em aparecer.

Conversando com diversos profissionais da área tenho a impressão de que estes apenas sabem da existência das plataformas que aparecem em revistas, sites e conferências: Java, .net, PHP, JavaScript, Python, Ruby. Me pergunto: e quanto ao pessoal do COBOL, que é responsável por processar 70% de todas as transações mundiais? Cadê o povo do Fortran, ainda em amplo uso em aplicações científicas, HPC e tantos outros usos? E estas aplicações desktop que vêmos em padarias, bares, restaurantes, hospitais, lojas? E todo o código em execução hoje feito em VBA em diversas empresas? Isto sem mencionar outras plataformas como Delphi (ainda em desenvolvimento e cada vez mais interessante), Visual Basic (pré .net (depois leia este texto)), Microsoft Access (quase VBA), Perl (hoje quase não se fala mais sobre, mas ainda executa muita coisa importantíssima por aí), Power Builder (última versão saiu em 2011), Clipper, FoxPro (morto pela Microsoft em 2007), PL/SQL, R (tão usado para cálculos estatísticos) e tantas outras plataformas?

Caminhando pelas ruas olho para os prédios e fico pensando na imensa quantidade de código gerado diáriamente que não é baseado em Java, .net, JavaScript, Python ou qualquer outra plataforma falada atualmente. São programadores que não veremos em revistas ou conferências: são pessoas que saem para trabalhar, geram valor real, movimentam a economia e vão tranquilamente para casa. Será que por serem ignorados (e muitas vezes se fazerem ignorados) não estamos perdendo uma oportunidade monstruosa de aprendermos lições valiosíssimas sobre arquitetura, boas práticas de desenvolvimento e toda a experiência acumulada na manutenção de sistemas legados?

Me sinto um privilegiado pelo fato da minha primeira experiência profissional de sucesso adulta ter sido em uma empresa de engenharia e não em uma fábrica de software. Foi neste ambiente que pela primeira vez pude constatar a riqueza de linguagens e plataformas: Delphi, Fortran, Perl, C, COBOL, Lisp (AutoLisp), VB, VBA eram minhas ferramentas do dia a dia. Java e .net representavam o moderno e mesmo assim ainda se mostravam inferiores no quesito produtividade. Era fato: com o ferramental antigo nós simplesmente entregávamos o que precisava ser feito e ainda por cima era código que podíamos manter e mantinhamos por anos.

(a coisa melhorou bastante: não estou dizendo que Java ou .net não sejam produtivos)

Ao passar para fábricas de software e mencionar algo como Delphi ou VB não raro ouço frases de arrogância extrema como "graças a Deus nunca tive de mexer com isto". Perguntando a razão por este "graças a Deus" normalmente a resposta vêm sob a forma de um "são coisa ultrapassada", "não prestam", "são lixo", "ninguém usa" (!!!) etc. Logo em seguida as mesmas pessoas vão almoçar e tem seu pagamento registrado em algum sistema feito em Delphi (ou VB, PowerBuilder), vão ao banco tirar seu saldo em um caixa eletrônico que acessa um sistema COBOL e logo em seguida pesquisam algo na Internet em um site baseado em CGI. Isto sem mencionar os que criticam PHP e passam o dia inteiro no Facebook. Claro: há também aquele código em VBA embutido em uma planilha Excel usado para calcular seu salário no final do mês. Uma vingança bastante irônica.

Ignorando gigantes

Recentemente ouvi um podcast fascinante sobre a plataforma System i da IBM, que foi lançada em 1988. O choque veio quando o entrevistado (Steve Will) falou a respeito do conjunto de instruções usado pela plataforma: o TIMI (Technology Independent Machine Interface). Todo software que executa no System i (ou quase todo) é compilado para este conjunto de instruções. Mudou a arquitetura dos processadores (32 para 64 bits ou CISC pra RISC, por exemplo) não precisa recompilar nada: o TIMI, que é um formato intermediário simplesmente se adapta para a nova plataforma. Lembra alguma coisa? No .net se chama CIL, no Java se chama bytecode. Surgem respectivamente em 1996 e 2002. TIMI provávelmente existia bem antes disto. (alguém aqui lembra do P-Code do Visual Basic?)

O interessante é que a plataforma System i é extremamente popular, usada por diversos estabelecimentos nos EUA e restante do mundo e difícilmente ouvimos algo a respeito (eu a conheci neste podcast).

Outro exemplo interessante: sabia que o CODASYL de 1957, responsável por definir o COBOL, previa a execução de código gerado dinâmicamente? E que o System/360, lançado em 1964 pela IBM já tinha recursos como máquinas virtuais, OCR e tantos outros que julgamos modernos hoje?

E ei: isto ocorre até nos dias atuais. Já leu meus dois posts (aqui e aqui) recentes sobre arquietura baseada em micro serviços nos quais mostro que estes na realidade são o SOA que já conhecíamos há anos mas cujo hype diminuiu nos últimos tempos?

De onde você acha que surgem idéias geniais como o bytecode Java, as máquinas virtuais da VM Ware e todos estes SGBDs que vêmos por aí? De onde você acha que o Oracle saiu (Daqui)? Fato é que esta nossa fixação no novo e ignorar do passado nos torna o "anti-newton": não vêmos além por ignorar os gigantes sobre os quais devíamos escalar os ombros.

Na minha opinião devíamos babar menos em cima do que nos vendem como novo e de vez em quando olhar para o prédio ou sala ao lado: muito provávelmente há um profissional entregando, gerando valor com tecnologias que vieram antes (e que funcionam perfeitamente bem) e aplicando soluções a problemas que ainda lutamos para entender (e nos vendem como novidade).

Baixar a cabeça e andar com estes gigantes discretos é sempre uma boa idéia. Estes não se preocupam em aparecer em conferências e blogs (normalmente não vão): enquanto discutimos sobre qual a melhor plataforma (Java ou .net, Node.js, Grails, Ruby) ou nos preocupamos em criar sistemas escaláveis que serão usados por no máximo uns 300 usuários/dia estes caras estão indo pra casa tranquilos por terem terminado seu trabalho.