Low Code, Heavy Battle

Desmistificando a Polémica atual sobre tecnologias Low-Code.

Essa semana o Twitter recebeu um spike de mensagens (ao menos em algumas timelines) sobre Low-Code. Como tudo em tecnologia, O tema em questão virou flame wars (eu não estando livre de ter participado, claro) e cada pessoa vestiu sua camisa, no melhor estilo Eleições Brasileiras 2018.

Assumidamente, eu participei da fogueira por um simples motivo: As ofensas ditas por Fabio Akita em seu canal do YouTube, e posteriormente parafraseadas por Edgar Berlinck, um dos podcasters do Devs Cansados, doeram. Não só em mim, mas em algumas pessoas no meu círculo pessoal.

Passado a chama, que agora é brasa, mencionaram que seria interessante eu escrever um texto sobre o tema, então vamos desmembrar esse assunto ponto por ponto:

1.Derrubando o primeiro pilar: “Isso, não é programação”

Programação de Computadores é o processo de desenhar e construir programas de computadores para cumprir um requisito ou tarefa computacional específico(a). Programação envolve diversas tarefas, como análise, geração de algoritmos e implementação de tais algoritmos em uma linguagem de programação específica.

A falácia deste argumento se baseia inteiramente na premissa de que existe um limite arbitrário de camadas máximas (ou níveis) onde o termo “programação” é aplicável. Para tal, utiliza-se (comummente) duas âncoras. A primeira delas é que um equipamento é “programável” quando o seu comportamento pode ser alterado. Isso é o que determina a diferença entre um ASIC e um PLD/CPU/APU/GPU/FPGA. Um deles tem o objetivo determinado no processo de construção, os outros, são compostos por um conjunto de componentes capazes de, em conjunto, receberem instruções que modificam seu comportamento. Isso é História da computação 101, Charles Babbage e Ada Lovelace…

Para os que queiram reduzir ainda mais o escopo do que é “programação”, pode-se aplicar os sistemas de regras de manipulação de dados que todo mundo já ouviu falar pelo nome: Turing completude.

É muito comum para programadores passearem entre as camadas da imagem 2 enquanto desenvolvendo sistemas, isso é uma prática normal. Todas elas são Turing completas pois todas elas permitem a criação de instruções específicas que permitem a manipulação de dados, e em última instância, permitem a criação de outra MTU. Este argumento é constantemente distorcido na expressão “Você pode criar X em X”, como por exemplo: “Você pode criar um Python usando Python”.
Este reducionismo é impreciso. Uma Máquina de Turing Universal precisa ser capaz de conseguir simular outra máquina de Turing ARBITRÁRIA com uma entrada ARBITRÁRIA. Isso não é o mesmo que “criar um Python usando Python”. Computacionalmente falando, uma MTU é mais simples, BEM mais simples que um Interpretador Python.

Tanto uma MTU é mais simples que um interpretador/compilador/Framework/Engine, que de tempos em tempos vê-se artigos do tipo: PowerPoint é Turing Completo.

Seja por um meio (Babbage/Lovelace) ou por outro (Turing), Ferramentas como OutSystems, Mendiz, Appian e PowerApps são programáveis, e por tanto, quem as programa, são programadores.

2.Derrubando o segundo pilar: “Se Low-Code é tão bom, porque tudo não migrou para Low-Code”

Essa é simples de derrubar. Qualquer pessoa que já trabalhou com desenvolvimento já ouviu falar da Lei dos Instrumento, ou do martelo de ouro, ou do martelo de Maslow.

Cada ferramenta (e isso se torna cada vez mais verdade quanto mais a abstração é elevada), serve melhor ou pior a alguns determinados propósitos. Utilizar Python para desenvolver sua própria versão do RabbitMQ vai apresentar alguns desafios muito complicados, devido a necessidade de velocidade, e sem um nível bem grande de “feitiçaria informática”, vai ser bem difícil fazer com que sua versão opere na mesma velocidade que o RabbitMQ opera. Isso acontece porque o RabbitMQ foi desenvolvido utilizando Erlang, uma linguagem que entre suas vantagens, apresenta um ganho considerável frente a Python em alguns dos pilares fundamentais para desenvolver uma ferramenta como esta.

É impossível? Não, não é, mas provavelmente você precisará desenvolver alguns componentes em mais baixos níveis para se integrar com o Python e prover os ganhos necessários para complementar os claros caveat desta tecnologia em específico. O mesmo acontece para todas as coisas. Tecnologias Low-Code servem a diversos objetivos. Existem ferramentas, ou construtores, como eu prefiro chamar, que são utilizados para programação de jogos, de sites, de equipamentos IoT, de serviços web e muito mais. Cada um deles apresenta suas vantagens e suas desvantagens, como qualquer outra tecnologia.

Eu posso responder esta afirmação com outra igual:

“Se LISP é tão bom, porque todo mundo não parou de usar outras linguagens e começou a usar LISP?”

3. Derrubando o terceiro pilar: “O conhecimento adquirido não se transmite se algum dia a suite Low-Code X morrer”

Todas as plataformas de desenvolvimento Low-Code que eu trabalhei tiveram sempre alguns pontos em comum:

• Todas elas utilizavam esquema MVC:
  Em Appian, Mendix e OutSystems, criam-se três tipos básicos de componentes. Páginas, Controladores e Modelos de domínio. Por motivos que só deus sabe, cada um deles decidiu nomear as coisas com nomes diferentes, mas é isto que eles são. No Mendix, o que eu tive mais prática, Se chamavam Pages, Microflows e Entity Models.
  Este formato é bastante utilizado para desenvolvimento Web e é muito comum vê-los em projetos em muitíssimas empresas. Se tu aprendeu o modelo MVC com uma destas ferramentas acima, eu lhe garanto que seu conhecimento é diretamente transferível para tecnologias de programação textual.
  

• Todas elas permitiam o desenvolvimento de Módulos próprias:
  ETQEU ^{(Em todas que eu usei)} é possível utilizar a linguagem de programação nas quais elas foram construídas para desenvolver módulos personalizados que expandem a utilidade das ferramentas. No OutSystems usa-se C#, no Mendix, usa-se Java (para backend) e Javascript/Typescript (para componentes visuais e lógica client side). Appian também utiliza Java, Javascript e Typescript. Eu diria que em 99% dos projetos que trabalhei, foi necessário criar as minhas, modificar as existentes ou corrigir algum erro presente em bibliotecas existentes. Para isso, não há como fugir muito, você irá precisar aprender programação nestas linguagens. Este conhecimento, como todos sabem, é plenamente transmissível para posições em outras tecnologias, porque Lógica de programação é lógica de programação, se você não quiser ir para outra linguagem, bem, você está com mais sorte ainda, o que não falta são vagas nestas linguagens.
  

• Todas elas utilizam formatos super tradicionais para modelagem de dados:
  Este talvez seja o ponto que menos muda dentre qualquer sistema SQL e modelagem de dados em plataformas de Low Code. Faz muito tempo que já se tornou “padrão” um formato de visualização para bases de dados, e por isso, foi onde eles menos inovaram na criação das suas interfaces gráficas (as famigeradas caixinhas). Para qualquer pessoa que sabe ler em inglês, não existe uma diferença entre as caixinhas azul (abaixo) e um Create Table … ;
  
  Imaginar que o conhecimento irá se perder pois você parou de trabalhar com Domain Model de tecnologias de low-code e e começou a trabalhar com SQL só pode ser dito por pessoas que nunca sequer viram um Domain Model de um destes sistemas (de nada, by the way, por mostrá-lo ai em baixo caso seja este o caso).

Considerações finais:

Eu já falei inúmeras vezes até em grupos de estudo e trabalho de Low-Code quando eu estava trabalhando com estas tecnologias. O mercado atual de Low-Code como um todo, ou seja, suas empresas, deram um grandessíssimo tiro no pé ao chamar estas tecnologias de “Low-Code” ao invés de simplesmente pegar um dos nomes das sopas de letrinhas que já foram usados para este tipo de software.

Poderiam ter se chamado de VPL, poderiam ter se chamado de RAD, poderiam ter se chamado de ENGINES… Mas pelo desejo de ser “trend”, deixaram os setores de marketing dar um nome que pisa em um povo que se magoa fácil, os programadores.

Depois disso, as empresas que lideram esse mercado deram um segundo tiro, dessa vez na barriga, ao fazer um marketing pesado em termos mais estúpidos ainda, como “Citizen Developer” ou, sinceramente, o PIOR DE TODOS: “Todos a programar, até padeiros“!

Eu entendo o motivo por trás disso. Eles querem pessoas começando a usar estas ferramentas, para depois ganhar dinheiro com o que eles realmente ganham, SaaS e SDaaS. Por isso que o Software do Mendix Studio é de graça, por isso que o OutSystems Studio é gratis, e por isso que ambos oferecem um “Free-Tier” para quem quiser ter suas soluções web criadas disponíveis online para seus clientes. Por isso que uma OutSystems Platform Standard Edition para 100 usuários finais custa 120 mil dolares por ano!

Outro ponto que eu considero MUITO problemático é que ao criar o termo “Low-Code” e depositar muito dinheiro em marketing para o popularizar, vem “os primos” para a festa. Muitos outros sistemas que são muito mais fechados, bem mais baratos e maioritariamente baseados no navegador começam a querer se aproveitar do que é Hype, oferecendo soluções de baixa qualidade, expansividade limitada e com lógica limitada, como ZOHO Creator por exemplo dentro da mesma nomenclatura que tanto recebeu investimento de algumas poucas empresas.
Eles chegam até mesmo ao ponto de distorcer estes termos e inventar versões que soam parecido, mas que na verdade só tem um adjetivo digno: INFERIORES (é o caso do tal do No-Code).

Eu trabalhei durante dois anos com OutSystems, Mendix e Appian. Durante grande parte deste tempo, trabalhei na Siemens, a proprietária da Mendix, na pŕopria Mendiz App Factory da Siemens Portugal.
Eu me certifiquei nos dois primeiros (OutSystems e Mendix) e posso dizer, principalmente sobre a Siemens, que lá eu conheci desenvolvedores extremamente capazes, altamente qualificados e que não deixavam nada a desejar para desenvolvedores React, Java, C# e etc. Trabalhávamos com tecnologias interessantes, usávamos Sass, Typescript, Java, GraphQL, Microsoft SQL, PostgreSQL e IoT, criávamos e consumíamos API’s REST e SOAP e um monte de outras coisas legais. E esse o motivo de eu ter entrado na Flame war que deu origem a este artigo.

Para mim, é muito doloroso e muito triste ver gente que nunca trabalhou com estes sistemas, nunca passou mais de um par de olhos na coisa, rebaixar esta equipe de profissionais fenomenal que eu conheci e respeito serem chamados de “Operadores”… Serem rebaixados ao equivalente tecnológico de um adolescente fazendo cup noodles, simplesmente porque eles não Programam da mesma forma que os mais tradicionais. Me dói duplamente quando eu vejo estas ofensas direcionadas a 200 mil seguidores em uma plataforma de nível mundial sendo replicada e ecoada por mais um monte de gente que igualmente nunca dedicou-se ou estudou o que estava a falar. Por isso eu quebrei o pau publicamente na Internet. Coisa que eu normalmente fujo de fazer. tanto que praticamente não tenho mídias sociais.

Minha opção de sair da Siemens me doeu muito. Eu estava já há alguns anos apaixonado pela minha segunda linguagem de programação (Go) depois de uma paixão (não muito correspondida) de oito anos por Lua.
Eu queria uma posição trabalhando com Go e queria seguir trabalhando com estes profissionais sensacionais que eu conheci no Tech Hub da Siemens Portugal, mas eles não utilizavam Go em nenhum projeto na empresa, e eu tive de os deixar por uma posição Junto a Teamwork, outra empresa com profissionais super sensacionais e que me surpreendem a cada dia. Sabe o que eu nunca ouvi deles? Nunca fui rebaixado por ter trabalhado com Low-Code.

Esta indústria foi construída por gente inovadora, por gente que ousou fazer diferente, ousou criar alternativas e refinamentos sobre tecnologias anteriores e igualmente inovadoras. Como diz a metáfora, nós estamos “Standing on the shoulders of giants“. Somos parte da área da Ada Lovelace, do Alan Turing, da Margaret Hamilton, do Kenneth Thompson, do Steve Wozniak e do John Kemeny. É aceitável você rebaixar outros desenvolvedores de IT só porque eles usam programação visual ao contrário de programação escrita?