Os fabricantes de ferramentas de baixo código e sem código (LC/NC) estão enfrentando uma batalha difícil tentando convencer as pessoas, especialmente desenvolvedores profissionais, a usar ou apenas experimentar suas ferramentas e plataformas. Algumas plataformas fizeram incursões nesse mercado, mas a maior parte do desenvolvimento de software, sem dúvida, ainda é feita por profissionais que escrevem códigos. Do ponto de vista dos fabricantes de ferramentas, a falta de interesse parece desconcertante. Desenvolvimento mais rápido, custos mais baixos, menos bugs, implantação mais fácil, ambientes gerenciados - por que alguém rejeitaria essa visão utópica que os fabricantes de ferramentas gostam de apresentar? Por que tantos preferem continuar sua batalha com idiomas difíceis, rastreamento de bugs complexos e configurações de ambiente obscuras? Tenho conversado com desenvolvedores, lido artigos e pesquisado fóruns de discussão para obter uma resposta a essas perguntas e reuni algumas das razões apresentadas. Não ajuda suas carreiras Aprender ferramentas de baixo código pode exigir um investimento significativo de tempo e esforço, mas há pouco valor profissional em aprender uma ferramenta LC/NC específica. Mesmo no caso raro de uma empresa de desenvolvimento de software usar uma ferramenta LC/NC, as habilidades que um desenvolvedor empregado adquire ao aprender essa ferramenta provavelmente não serão exigidas pelo próximo empregador. A maioria dos trabalhos de desenvolvimento exige conhecimento e experiência aprofundados com linguagens e estruturas amplamente usadas e nenhuma ferramenta de baixo código é tão usada quanto React, Angular, Python, Java ou C#. Muito poucos trabalhos de desenvolvimento exigem conhecimento de ferramentas LC/NC e a probabilidade de um desenvolvedor encontrar um emprego melhor ou ganhar mais dinheiro sabendo que uma ferramenta LC/NC é muito baixa. Portanto, é melhor para os desenvolvedores gastar tempo aprendendo e aperfeiçoando uma das inúmeras habilidades, estruturas e linguagens que estão em alta demanda no mercado de trabalho. Os desenvolvedores passaram anos aprendendo a escrever código Quase 70% dos desenvolvedores que responderam ao declararam ser bacharéis ou superiores em Ciência da Computação ou áreas afins. Isso significa que a maioria dos desenvolvedores investiu anos estudando programação, aprendendo várias linguagens, arquiteturas de sistemas e, em geral, praticando e aperfeiçoando a arte de escrever código. Usar ferramentas LC/NC geralmente significa abrir mão das vantagens que sua experiência e investimento suado representam. Portanto, não é surpresa que a maioria dos desenvolvedores prefira apostar em habilidades valiosas que já adquiriram laboriosamente. Pesquisa do Desenvolvedor Stack Overflow 2021 Se as ferramentas LC/NC realmente entregarem o que prometem, escrever código para criar aplicativos não será mais necessário no futuro. A programação passará para um nível mais alto de abstração e os aplicativos serão montados a partir de componentes existentes, em vez de codificados. Portanto, os programadores basicamente ameaçam tornar redundantes suas habilidades adquiridas com muito esforço, usando e apoiando o aumento do uso de ferramentas LC/NC. Portanto, é do interesse deles que as ferramentas LC/NC não sejam bem-sucedidas. Os desenvolvedores se preocupam menos com a velocidade Quando os desenvolvedores trabalham para empresas de software, eles são pagos para entregar código com características específicas. Isso inclui ser fácil de ler, testável, bem estruturado, confiável, eficiente, seguir padrões e assim por diante. Os desenvolvedores que mantêm aplicativos moderadamente complexos apreciarão a importância de garantir que o código seja o mais simples possível e de fácil compreensão. Essas qualidades são essenciais para que o código seja sustentável. O código geralmente é revisado por um programador mais experiente que também se preocupa com essas qualidades e reforça a ênfase nelas. Eles podem ter um interesse maior em fazer as coisas mais rapidamente do que o desenvolvedor, mas sabem que o código com erros, ineficiente, escrito de forma criptografada e difícil de estender é difícil de manter. Esse código ruim pode causar muitos problemas e se tornar muito caro no futuro. Embora a velocidade com que o código é entregue seja relevante, a forma como o código é organizado e escrito geralmente tem precedência sobre a velocidade com que foi entregue. Portanto, divulgar a velocidade de desenvolvimento de ferramentas LC/NC para desenvolvedores pode não ter o impacto esperado. Os desenvolvedores gostam de codificar As pessoas são vagas e emocionais. Eles têm prioridades conflitantes, muitas vezes são inseguros, imprecisos e mentem. Freqüentemente, eles nem sabem o que estão fazendo e por que estão fazendo. As pessoas podem ser muito confusas. Os computadores são muito mais simples. O computador simplesmente segue as instruções fornecidas pelo programador e, se essas instruções estiverem incorretas, o programa falha. A precisão em definir um conjunto de tarefas e vê-las executadas de forma imediata e exata dá a muitas pessoas uma sensação de segurança e alegria. Há um elemento criativo na codificação que muitos desenvolvedores realmente apreciam. A programação é um quebra-cabeça muito complexo, cheio de quebra-cabeças, abrangendo dezenas de módulos, várias camadas e milhares de linhas de código. Um único aplicativo da Web pode facilmente envolver cinco ou mais linguagens diferentes trabalhando juntas (por exemplo, HTML, JS, CSS, C#, SQL). Modelar objetos complexos de partes móveis interligadas e observá-los trabalhar em ciclos sutis enquanto representam as consequências da lógica incorporada a eles pode ser fascinante e trazer um forte senso de realização. A razão pela qual o software existe é para tornar a vida mais fácil e, fundamentalmente, construímos software para ajudar as pessoas a fazer as coisas melhor. Depois de aprender a escrever código - em qualquer idioma - você pode construir qualquer coisa que imaginar. Há alegria em imaginar algo e depois criá-lo do nada, especialmente quando é útil para os outros e os deixa felizes. Os desenvolvedores não escolhem pilhas de tecnologia Quanto mais tempo um desenvolvedor permanece em um projeto, melhor ele consegue estender o aplicativo e mais eficiente ele se torna em encontrar e corrigir problemas. Quando os desenvolvedores deixam seus empregos, eles geralmente levam consigo um conhecimento íntimo sobre os detalhes intrincados dos aplicativos. Esse conhecimento é muito difícil de recuperar e quando tais funcionários são substituídos, os aplicativos que eles suportavam muitas vezes entram em uma fase de instabilidade e às vezes até de caos. Portanto, embora as empresas de software tenham interesse em estabilidade, os desenvolvedores de software geralmente ficam com um empregador por alguns anos. Uma estratégia que as empresas de software empregam para mitigar a perda de conhecimento é usar tecnologias amplamente utilizadas e conhecidas na comunidade de desenvolvedores. O uso de pilhas conhecidas facilita a localização de pessoas qualificadas para empregar. Também ajuda essas pessoas a aprender os detalhes dos aplicativos criados com eles. Os desenvolvedores podem ser influenciadores na decisão de quais tecnologias usar para um projeto, mas geralmente são os engenheiros seniores ou mesmo a gerência que decidem sobre as pilhas usando esses critérios. Ferramentas de marketing LC/NC para desenvolvedores podem, portanto, errar o alvo. Apostar em uma ferramenta é arriscado Os clientes tendem a ser difíceis de definir para onde podem levar um aplicativo no futuro. Isso é compreensível, pois o futuro é muito difícil de prever. Portanto, os proprietários de aplicativos precisam se adaptar às necessidades de mudança para garantir o sucesso comercial de um aplicativo. Isso geralmente significa alterar os modelos de negócios e alterar as tecnologias que possibilitam esses modelos. Desenvolvedores experientes sabem disso e gostam de construir sistemas abertos que possam ser adaptados às mudanças de necessidades no futuro. A melhor maneira de criar esses sistemas adaptáveis é codificá-los usando linguagens e estruturas bem suportadas. Muitas ferramentas LC/NC são novas, imaturas e vêm com limitações técnicas significativas. Esses limites geralmente não são anunciados e, muitas vezes, apenas documentados de forma esparsa. A única maneira de as empresas de software encontrarem esses limites é experimentar uma ferramenta e criar um aplicativo real. A maioria das limitações só se tornará aparente após um investimento significativo de tempo e esforço. O desenvolvimento de software é caro e arriscado, e essas incógnitas aumentam ainda mais o risco para desenvolvedores, empresas de software e seus clientes. Lock-ins selam o acordo Muitas plataformas não permitem que aplicativos construídos nessa plataforma sejam exportados para formatos genéricos e editáveis. Eles bloqueiam os aplicativos, amarrando o desenvolvedor à plataforma ou exigindo que eles reconstruam o aplicativo do zero. Considerando que os requisitos futuros são incertos e que as limitações das ferramentas LC/NC muitas vezes permanecem ocultas até o final do projeto, não é de surpreender que os desenvolvedores possam ser extremamente cautelosos para não ficarem presos. LC/NC falhou muitas vezes no passado As ferramentas de desenvolvimento visual não são novas. As primeiras tentativas de desenvolvimento visual já foram feitas há 50 anos. Desde então, uma infinidade de plataformas e ambientes de desenvolvimento visual bons e ruins surgiram e desapareceram e nenhum deles fez uma diferença significativa na maneira como os aplicativos são criados. Quem apostou em qualquer uma dessas ferramentas, investiu tempo e energia em aprendê-las e convenceu clientes a construir seus projetos em qualquer uma delas perdeu a aposta. Essa história sugere que é improvável que qualquer uma das ferramentas que encontramos hoje ainda esteja disponível daqui a uma década. Muitos desenvolvedores podem considerar esses fatos cuidadosamente e decidir que LC/NC é um beco sem saída. O que agora? Então, LC/NC é uma causa perdida e não há lugar para LC/NC no mundo do desenvolvimento de software sério? Os fabricantes de ferramentas LC/NC podem de alguma forma superar essas barreiras e motivar mais desenvolvedores a usar produtos LC/NC? Muitos desenvolvedores preferem o código devido à falta de confiança nas ferramentas LC/NC e na comunicação de marketing que as anuncia. Para convencer qualquer profissional a usar uma plataforma LC/NC, os fabricantes de plataformas exigem que os desenvolvedores confiem neles. Para construir essa confiança, os fabricantes de ferramentas fariam bem em ouvir as preocupações dos desenvolvedores e das empresas de software apresentadas e levá-las em consideração ao planejar os recursos da plataforma e ao se comunicar com os grupos-alvo. A divulgação honesta e verdadeira de limitações funcionais, a publicação de maneiras de superar limitações, achatando a curva de aprendizado para plataformas e permitindo a exportação de aplicativos para formatos editáveis são, embora possam não convencer todos os desenvolvedores, passos na direção certa.

Stacks

Target

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Low Code

2022 - HackerNoon Contributor of the Year - Psychology

2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Low Code

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Psychology

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Making security fun one episode at a time

8 coisas que os desenvolvedores não gostam em Low-Code e No-Code

8 coisas que os desenvolvedores não gostam em Low-Code e No-Code

Muito longo; Para ler

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

8 coisas que os desenvolvedores não gostam em Low-Code e No-Code

Muito longo; Para ler

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

Rótulos

Languages

ESTE ARTIGO FOI APRESENTADO EM...

HISTÓRIAS RELACIONADAS