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.
Perfeito!
Só faltou comentar que normalmente esses profissionais (principalmente a galera do COBOL) ganham muito mais que os programadores “moderninhos”.
Opa, obrigado Rene.
Tocou no ponto: fato. E não só COBOL: conheço programadores Delphi, VB e C que ganham ordens de magnitude mais.
Este pessoal (esta massa) sempre me cativou: de uns tempos pra cá quando vejo estas chamadas de conferências e vejo quem está falando tenho a impressão de que estou em um daqueles eventos “YouTuber Gamer”, sabe?
É quase como se eu ouvisse um palestrante entrar e nos saudar com um “E aí pessoal? Tuuuudo beeeem? Aqui quem fala é o Edu e… galera, é o seguinte:” (tipo isto: https://www.youtube.com/user/BRKsEDU)
Trabalho no Banco Central e a principal linguagem da equipe é o Natural.
E são eles que realmente entregam o verdadeiro valor.
Os projetos Java, nos quais eu trabalho, são “pequenos” se comparados com os sistemas deles.
Eles rodam toda a parte de folha de pagamento do banco.
Acho estranho o jeito deles programarem… Usando aqueles terminais parecidos com um DOS, mas é isso que gera valor lá no BACEN.
Outra galera que eu acho q entrega bastante valor e é meio invisível é a galera do SAP/Abap.
Oi Lazaro, muito bem lembrado!
E tem também a galera que trabalha com linguagens 4GL. O pessoal do Progress (DataSul), ADVPL (Microsiga), Abap que você citou e tantos outros.
Ótimo post Kiko!
Realmente, esse preconceito de linguagens é algo a ser abominado. As linguagens antigas, sim, entregam muito valor. Ainda que exista um respiro forte dos “novos revolucionários” em sempre querer alterar o “legado”, em atualizar os ambientes para os “novos tempos e tecnologias do futuro”. Cada sistema com sua arquitetura e realidade que esteja relacionada a ele.
Adorei ver esses números impressionantes do COBOL, não tinha idéia da maciça máquina de processamento do mesmo. Não a toa os sistemas bancários não abdicam dos seus “legados” em mainframe tb.
Achei essa parte genial:
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.
Oi Rodrigo, que bom que gostou, valeu!
O motivo de eu particularmente não me interessar é que ja trabalhei em banco com cobol, ja trabalhei em empresa de automação comercial com clipper, desenvolvimento totalmente go horse, arquitetura 0, orientação a objeto 0, coisas funcionando na tentativa e erro, e eu admiro a arte de programar, se gera valor ou não, eu não me importo, e sim se contribui com meu desenvolvimento profissional, se contribui com a arte.
Em segundo lugar o motivo de não migrarem o legado para uma tecnologia moderna no caso do banco em que eu trabalhava* é principalmente o baixo custo de formar programadores cobol em 1 mes o cara faz tudo., não tem milhoes de frameworks pra aprender nem nada, é go horse escreve um monte de função e if e pronto, você tentar conversar de arquitetura com um cara desse é inútil por que o cara só sabe que funciona e pronto, e cobol é a mesma linguagem pequena de anos atras e não tem o que inventar, e o custo de servidores de aplicação, banco de dados, todo perigo de realizar esse tipo de migração, sendo que para a empresa não teria aparentemente “vantagem nenhuma em migrar” resumindo ta funcionando não mexe , vamos continuar pagando os mainframes e ta tudo bem.
Último ponto sobre salários, nunca vi nenhum cara que Não trabalhe a vida toda na mesma empresa ganhar “bem” com cobol, inclusive jrs de cobol no caso tinha salario menor que de java, resumindo dinossauros ganhão bem em qualquer linguagem, fora que o mercado é muito menor você tem opções limitadas de empresas para trabalhar, isso pode ate elevar o salários se o cara é bom, mais eu particularmente não gosto desse mercado limitado.
Só lembrando minha opinião pessoal, não tenho nada contra mais acho que não perco nada.
Oi Bruno, muito obrigado por compartilhar sua experiência!
Interessante o que diz: aliás, apesar da sua experiência aparentemente não ter sido positiva há um aspecto interessantíssimo no que você menciona: a aparente facilidade em se treinar os profissionais. Este foi o aspecto que mais me chamou a atenção.
Claro: a gente não pode generalizar né? Uma experiência ruim não quer dizer que todas sejam.
O que observo ao estudar a arquitetura de mainframes é que muito do que nos vendem hoje como novidade já é cotídiano de uma infinidade de programadores. Este é o grande ganho para mim: uma fonte de inspiração e aprendizado gigantesco quando observamos com mais cuidado a tecnologia envolvida nestes cenários que citei.
sim sempre tem o que aprender.
Acho válida a opinião do colega, mas o trecho a seguir decepciona:
eu admiro a arte de programar, se gera valor ou não, eu não me importo, e sim se contribui com meu desenvolvimento profissional, se contribui com a arte.
Gosto de pensar que Desenvolver Software não é uma arte, mas uma profissão.
Explico: arte seria algo feito pelo puro valor estético. Já em uma profissão fazemos “troca de valor”: somos pagos para fazer algo útil para nossos clientes.
Até o Stallman [1] acha que programação é menos arte do que profissão:
I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making things purely for their beauty.
[1] http://developers-beta.slashdot.org/story/05/07/05/2158213/is-programming-art
Seu ponto é 120% válido Alexandre.
Concordo com você: nosso foco é enriquecer quem nos contrata através do resultado do nosso trabalho (gerar valor). Não sei se programar por programar faria qualquer sentido.
Aliás, nem arte por arte sequer existe. Sempre você faz algo para alguém, e com o objetivo de que o comprador/apreciador goste do seu trabalho por alguma razão.
Este “gostar por alguma razão”, “justificativa por trás de uma escolha” tem um nome: valor.
Ia comentar a mesma coisa Alexandre, o ato de programar não pode ser um considerado arte, não é sazonal. Devemos programar tão bem num dia bom quanto num dia ruim, e não depender de inspiração, e sim de seguir a metodologia a risca. Afinal, nós programadores somos meros operários.
Ótimo post Kico! Pena que hoje poucos tenham essa visão e as instituições de ensino não apresentem para os novos esses verdadeiros casos de sucesso que estão ai há décadas.
Oi Julio, valeu!
É algo que percebo também: não ouvimos falar sobre mainframes nas faculdades, no entanto vêmos no dia a dia que muito do que nos apresentam hoje como novo sai justamente de lá. E este é apenas um exemplo.
O que observo também é que o cara sai da faculdade uma espécie de “CRUD maker”, e não cientista da computação, o que considero muito preocupante.
Aqui no SERPRO a maioria dos sistemas ainda são feitos dobradinha Natural/ADABAS!
Siscomex, Cadastros de CPF e CNPJ, IRPF e IRPJ, etc…
E quando botam algono Java, muitas vezes é só como front-end ou apenas parte do negócio, sendo o coração continuando em Natural.
Trezentos usuariozinhos? Quero ver ler uma base com mais de 25.600.000 registros e entregar o resultado sem abrir o bico (Siscomex Exportação)!
Oi Franklin, fato.
Oi Franklin, eu só trocaria o verbo: não é “ainda são feitos”, mas sim “são feitos”.
Natural/Adabas não é uma tecnologia do passado, mas sim com passado. Este é o grande ponto que as pessoas ignoram.
Ter passado, ter 30, 40 anos de história significa que são décadas de desenvolvimento em cima da coisa, quer dizer que temos uma plataforma estável, que funciona (BEM).
O que vejo por aí muito é surgir algo do zero (exemplo clássico: Node.js) e o pessoal pular em cima com tudo pelo simples fato de ser algo saido do forno e não por suas características intrínsecas.
é essa moda de node.js ja esta chata.
Não querendo ser chato. mais somente lembrando que você deve considerar o alto custo de um main frame e o numero de processadores e memoria que é abundante, provavelmente se você tiver um servidor com o mesmo numero de processadores e memoria talvez algo assim como isso http://www.oracle.com/br/products/database/exadata/overview/index.html
mais para aplicação também não apenas para o banco, você consiga mais performasse, como falei acredito que o custo da migração é inviável, e considerando outros problemas como o volume de dados ja existente.
So para citar eu trabalho no uol e por exemplo a home tem mais de 20 mil requests por segundo e se voce olhar a home vai ver o tanto de anuncios que tem la para serem calculados, o pagseguro volume altissimo de transações, o sistema de anúncios patrocinados tipo google adsence tem que a cada visualização de qualquer parceiro fazer vários cálculos complexos, o batepapo é um dos sites mais acessados do brasil em que os usuarios ficao online o tempo todo. segundo isso aqui http://www.infomoney.com.br/minhas-financas/gadgets/noticia/2961393/sites-mais-acessados-brasil-segundo-site-alexa é o quinto site mais visto do brasil.
e é absolutamente tudo java =), e acredito que o custo das maquinas em produção não chega perto de um main frame.
Resumindo citei o uol porque não acho que exista bala de prata e que nem todos os sistemas são para 300 usuários, e que existem sim altos custos de migração só para terminar vamos lembrar q o banco para de transacionar praticamente depois das 22 provavelmente para realizar processamentos em lote, e fica somente leitura, resumindo stop the world. Eu particularmente não desdenho de tecnologias antigas todo mundo sabe que adabas é mto rápido e tal,só que ai me pergunto por que o banco para de transacionar as 22h? que tosco? cheira a go horse eu não sei mais particularmente fico puto quando quero comprar algo as 23h e o banco diz que o horário limite foi excedido, peço para meus amigos pagarem e o banco deles da o mesmo erro.