Sou cético em relação ao low-code

• Tenho uma postura cética em relação ao low-code
• Ao trabalhar com consultoria de software, frequentemente encontro clientes atraídos por anúncios que prometem tempo de desenvolvimento rápido e baixos custos de manutenção com low-code
• Existem alguns motivos pelos quais os clientes não ficam satisfeitos

Limites das funcionalidades personalizadas

• As soluções low-code atendem cerca de 80% dos requisitos de uma empresa, mas os 20% restantes não podem ser resolvidos com os recursos padrão
• Os profissionais de marketing das ferramentas low-code afirmam que os 20% restantes podem ser resolvidos facilmente, mas, na prática, isso exige uma personalização considerável e às vezes é impossível
• A empresa precisa escolher se os recursos padrão da ferramenta são próximos o suficiente, ou se tentará hackear a ferramenta para adequá-la exatamente ao seu caso de uso

Limitação do pool de desenvolvedores

• Às vezes, as empresas tentam hackear ferramentas low-code para atender 100% dos requisitos
• Como resultado, acabam escrevendo muito código personalizado em uma ferramenta específica ou em uma linguagem proprietária, e há pouquíssimos desenvolvedores capazes de entendê-lo
• Agora, em vez de contratar a partir do pool de desenvolvedores de linguagens open source amplamente usadas, a empresa precisa encontrar um mantenedor altamente especializado nessa ferramenta

Problemas nas atualizações da plataforma

• Ao atualizar um software, é difícil garantir que as integrações não quebrem
• Ferramentas low-code precisam lidar com código arbitrário para casos de uso para os quais elas não foram projetadas
• Isso deveria ser possível por meio de contratos de API rígidos, mas, na prática, vejo muito código personalizado aprontando de tudo internamente

Confusão na estrutura do banco de dados

• Vejo empresas usando ferramentas low-code em processos nos quais análises precisas são essenciais
• No entanto, quando se olha para o modelo de dados subjacente, tudo fica incompreensível: o que significa user_attribute_47? Se um campo é movido da página 1 para a página 2 do aplicativo, os dados ficam em um campo separado?

Opinião do GN⁺

• O low-code é uma ferramenta promissora para reduzir o tempo de desenvolvimento e os custos de manutenção, mas, no uso real, podem surgir problemas inesperados.
• Especialmente quando são necessárias funcionalidades personalizadas, ou quando se depende de linguagens de desenvolvimento ligadas a uma ferramenta low-code específica, o pool de desenvolvedores fica mais restrito e a manutenção se torna mais difícil.
• As atualizações das ferramentas low-code e a complexidade da estrutura do banco de dados são pontos importantes a considerar na gestão de projetos de longo prazo.
• Este texto aponta cuidados necessários ao usar ferramentas low-code e oferece insights interessantes ao recomendar uma avaliação criteriosa dos casos de uso adequados.

[ats62]

Acho que, até agora, o conceito de no-code tem sido aplicado de forma limitada em áreas específicas.

Quando surgirem serviços bem feitos usando LLM, sinto que antes de tudo o conceito de no-code vai mudar — a tendência? o fluxo? a direção? enfim, o próprio conceito.

[quack337]

Conheço um caso, de cerca de 10 anos atrás, em que o MS Access foi usado de forma útil.

No sistema de informação da organização, havia um banco de dados relativamente bem projetado e implementado em MS Sql Server,
e as tarefas rotineiras de OLTP também estavam relativamente bem implementadas.

No entanto, havia um acúmulo de insatisfação com a resposta lenta e pouco proativa do departamento de TI às demandas não rotineiras de consulta de dados e geração de relatórios.

Um funcionário da área de negócios, que dominava bem o MS Excel e o Access, mostrou que era possível importar para o Access os dados em Excel baixados do sistema de informação e implementar, sem programação, em apenas algumas horas, as funções necessárias de consulta de dados e emissão de relatórios.

[quack337]

O departamento de negócios solicitou acesso para se conectar diretamente ao banco de dados pelo Access, e o departamento de TI se opôs a expor o banco de dados do sistema de informação à rede externa. Ainda assim, como a demanda do departamento de negócios era forte, foi criado e exposto separadamente um banco de dados espelhado contendo apenas parte dos dados.

Os funcionários que sabiam usar bem os recursos de dados do Excel começaram a utilizar o Access no trabalho após apenas alguns dias de treinamento.

[tequila]

Eu me identifico com esse texto. Na minha opinião pessoal,
quando se usa uma sintaxe especial -> é preciso uma curva de aprendizado, e a manutenção fica mais difícil
quando a UI apenas substitui o código de forma simples -> muitas vezes é mais prático simplesmente programar
quando vira uma ferramenta totalmente no-code -> há muitas limitações, e isso incentiva os usuários a fazer gambiarras. A frequência de usuários fazendo coisas fora do comportamento pretendido aumenta bastante
Resultado: vira uma ferramenta que não consegue satisfazer ninguém.
A distância entre planejamento, desenvolvimento e usuários é grande demais, então parece ser uma área bem mais difícil de fazer direito do que se imagina.

[GN⁺]

Opinião do Hacker News

• Várias perspectivas sobre low-code

  • Perspectiva de um desenvolvedor de plataforma low-code

    Low-code é fácil de vender. Usa a estratégia de transformar o departamento de TI no problema e explorar insatisfações existentes. Nas demos, mostra tarefas simples sendo feitas rapidamente. Mas é melhor não colocar a lógica central do negócio dentro do low-code. Parte do princípio de que tarefas complexas serão descarregadas para sistemas especializados. É útil em grandes empresas para equipes que têm conhecimento técnico, mas pouca autoridade sobre TI. Low-code resolve muitos problemas com ferramentas simples, mas escala mal e precisa colaborar com sistemas centrais robustos.

  • Perspectiva de um SRE (engenheiro de confiabilidade de site)

    É cético em relação a low-code. Falta controle de código-fonte e a documentação não é boa. Muito código customizado é necessário, mas a reutilização é baixa. Exige runtimes proprietários e é difícil de monitorar. Na prática, não vê casos em que engenheiros fazem o trabalho e não engenheiros usam o resultado. Ferramentas como Looker permitem integração com código-fonte, mas ainda assim são usadas por engenheiros. Comprime a complexidade, mas prefere plataformas que possam ser personalizadas e estendidas conforme necessário.

  • Perspectiva sobre a plataforma low-code da Microsoft

    Tinha interesse na plataforma low-code da MS, mas ela parece ter sido construída de forma complexa sobre O365 e Azure. A interface do usuário é fraca, e no longo prazo as perdas causadas por problemas de usabilidade podem ser maiores do que qualquer economia de custos.

  • Experiência de negócio migrando soluções de banco de dados/formulários em MS-Access

    Construiu um negócio migrando soluções em MS-Access criadas por não desenvolvedores/usuários finais sem passar pelo departamento de TI para verdadeiras aplicações cliente/servidor em .net. Soluções low-code são úteis para resolver alguns problemas ou fazer um POC funcionar, mas podem causar problemas quando é preciso escalar ou adaptar.

  • Perspectiva de um desenvolvedor do construtor de sites SQLPage

    Soluções low-code precisam ter uma saída de escape para interagir com APIs externas de "high-code". No SQLPage, isso é oferecido por meio de sqlpage.exec. Existe o problema de upgrades da plataforma low-code quebrarem implementações personalizadas. A maioria das ferramentas low-code toma os dados como reféns, mas o SQLPage adiciona uma camada sobre um banco de dados que o usuário ainda pode controlar totalmente.

  • Opinião contrária sobre ferramentas low-code de nível corporativo

    É contra ferramentas low-code usadas por grandes empresas. Grandes empresas deveriam ser capazes de bancar equipes de desenvolvimento adequadas, planejamento e organização. Não é o código que gera custo, e sim desenvolvedores ruins usando ferramentas ruins para tomar decisões ruins.

  • Perspectiva sobre low-code e camadas de abstração

    "Low-code" tem uma superfície menor de código com a qual se pode interagir diretamente, mas na prática há muito código escondido. Camadas de abstração são poderosas quando se ajustam bem ao propósito, mas podem causar problemas quando vazam ou são inadequadas. Em geral, low-code abstrai código ajustado para usos específicos, mas na prática ainda exige experiência no domínio específico.

  • Experiência de construir um MVP usando Bubble/Airtable

    Recebeu uma estimativa de uma equipe ucraniana para construir um MVP, mas contratou um estagiário e criou o produto em dois meses usando Bubble/Airtable, conseguindo clientes pagantes em até 6 meses. Por quase dois anos, não encontrou motivo para migrar para uma stack tradicional.

  • História de terror no desenvolvimento de um curso de treinamento low-code

    Uma empresa importante desenvolveu cursos internos de treinamento para equipes de marketing e vendas usando um pacote de software low-code para criação de cursos. Anos depois, surgiu a necessidade de atualizar os cursos, mas houve problemas porque já não existiam o software usado no desenvolvimento nem ferramentas capazes de fazer o trabalho.

  • Questionamento sobre a possibilidade de versionamento em implementações low-code

    Levanta dúvidas sobre colocar implementações low-code sob controle de versão, encontrar a causa de problemas quando algo dá errado e fazer rollback para um commit específico usando ferramentas gratuitas. Na maioria dos casos, esses recursos não existem, o que as torna inadequadas para uso sério.