8 choses que les développeurs n'aiment pas à propos du low-code et du no-code

Les fabricants d'outils low-code et no-code (LC/NC) sont confrontés à une bataille difficile pour essayer de convaincre les gens, en particulier les développeurs professionnels, d'utiliser ou même simplement d'essayer leurs outils et plates-formes. Quelques plates-formes ont fait des percées sur ce marché, mais la majorité du développement de logiciels est sans aucun doute toujours effectuée par des professionnels qui écrivent du code.

Du point de vue des fabricants d'outils, le manque d'intérêt semble perplexe. Un développement plus rapide, des coûts réduits, moins de bogues, un déploiement plus facile, des environnements gérés - pourquoi quelqu'un rejetterait-il ces fabricants d'outils de vision utopique aiment présenter ? Pourquoi tant de personnes continuent-elles à se battre avec des langages difficiles, des traçages de bogues complexes et des configurations d'environnement obscures ?

J'ai parlé à des développeurs, lu des articles et parcouru des forums de discussion pour obtenir une réponse à ces questions et j'ai rassemblé certaines des raisons avancées.

Cela n'aide pas leur carrière

L'apprentissage d'outils low-code peut nécessiter un investissement important en temps et en efforts, mais il y a peu de valeur professionnelle dans l'apprentissage d'un outil LC/NC spécifique. Même dans les rares cas où une société de développement de logiciels utilise un outil LC/NC, les compétences qu'un développeur employé acquiert en apprenant cet outil ne seront probablement pas requises par le prochain employeur.

La plupart des travaux de développement exigent une connaissance et une expérience approfondies des langages et des frameworks largement utilisés et aucun outil low-code n'est aussi largement utilisé que React, Angular, Python, Java ou C#.

Très peu d'emplois de développement nécessitent une connaissance des outils LC/NC et la probabilité qu'un développeur trouve un meilleur emploi ou gagne plus d'argent en connaissant un outil LC/NC est très faible. Ainsi, les développeurs feraient mieux de passer du temps à apprendre et à perfectionner l'une des myriades de compétences, de frameworks et de langages très demandés sur le marché du travail.

Les développeurs ont passé des années à apprendre à écrire du code

Près de 70 % des développeurs qui ont répondu à la Enquête 2021 sur les développeurs Stack Overflow ont déclaré détenir un baccalauréat ou un diplôme supérieur en informatique ou dans une matière connexe. Cela signifie qu'une majorité de développeurs ont investi des années dans l'étude de la programmation, l'apprentissage de divers langages, les architectures système et, de manière générale, la pratique et le perfectionnement de l'art d'écrire du code. Utiliser des outils LC/NC signifie souvent renoncer aux avantages que représentent leur expérience et leur investissement durement acquis. Il n'est donc pas surprenant que la plupart des développeurs préfèrent miser sur des compétences précieuses qu'ils ont déjà laborieusement acquises.

Si les outils LC/NC tiennent réellement leurs promesses, l'écriture de code pour créer des applications ne sera plus nécessaire à l'avenir. La programmation passera à un niveau d'abstraction plus élevé et les applications seront assemblées à partir de composants existants plutôt que codées. Ainsi, les programmeurs menacent essentiellement de rendre redondantes leurs compétences durement acquises en utilisant et en soutenant l'utilisation accrue des outils LC/NC. Il est donc effectivement dans leur intérêt que les outils LC/NC ne réussissent pas.

Les développeurs se soucient moins de la vitesse

Lorsque les développeurs travaillent pour des éditeurs de logiciels, ils sont payés pour fournir un code présentant des caractéristiques spécifiques. Il s'agit notamment d'être facile à lire, testable, bien structuré, fiable, efficace, conforme aux normes, etc. Les développeurs qui gèrent des applications même modérément complexes apprécieront à quel point il est important de s'assurer que le code est aussi simple que possible et facilement compréhensible. Ces qualités sont essentielles pour que le code soit maintenable.

Le code est généralement révisé par un programmeur plus expérimenté qui se soucie également de ces qualités et met l'accent sur elles. Ils pourraient avoir plus d'intérêt à faire avancer les choses plus rapidement que le développeur, mais ils savent qu'un code bogué, inefficace, écrit de manière cryptée et difficile à étendre est difficile à maintenir.

Ce mauvais code peut causer beaucoup de problèmes et devenir très coûteux en bout de ligne. Bien que la vitesse à laquelle le code est livré soit pertinente, la manière dont le code est organisé et écrit prime généralement sur la vitesse à laquelle il a été livré.

Ainsi, la commercialisation de la vitesse de développement des outils LC/NC auprès des développeurs peut ne pas avoir l'impact escompté.

Les développeurs aiment coder

Les gens sont vagues et émotifs. Ils ont des priorités conflictuelles, sont souvent incertains, inexacts et mentent. Souvent, ils ne savent même pas ce qu'ils font et pourquoi ils le font. Les gens peuvent être très confus. Les ordinateurs sont beaucoup plus simples. L'ordinateur suit simplement les instructions qui lui ont été données par le programmeur et si ces instructions sont incorrectes, le programme échoue. La précision dans la définition d'un ensemble de tâches et leur réalisation immédiate et précise procurent à de nombreuses personnes un sentiment de sécurité et de joie.

Il y a un élément créatif dans le codage que de nombreux développeurs apprécient vraiment. La programmation est un puzzle très complexe, plein de casse-tête, couvrant des dizaines de modules, plusieurs couches et des milliers de lignes de code. Une seule application Web peut facilement impliquer cinq langages différents ou plus travaillant ensemble (par exemple, HTML, JS, CSS, C#, SQL). Façonner des objets complexes de pièces mobiles imbriquées et les regarder fonctionner dans des cycles subtils alors qu'ils jouent les conséquences de la logique qui y est intégrée peut être fascinant et apporter un fort sentiment d'accomplissement.

La raison pour laquelle les logiciels existent est de rendre la vie plus facile et nous concevons fondamentalement des logiciels pour aider les gens à mieux faire les choses. Une fois que vous savez comment écrire du code - dans n'importe quel langage - vous pouvez créer tout ce que vous pouvez imaginer. Il y a de la joie à imaginer quelque chose puis à le créer à partir de rien, surtout quand cela est utile aux autres et les rend heureux.

Les développeurs ne choisissent pas les piles technologiques

Plus un développeur reste longtemps sur un projet, plus il réussit à étendre l'application et plus il devient efficace pour trouver et résoudre les problèmes. Lorsque les développeurs quittent leur emploi, ils emportent souvent avec eux des connaissances intimes sur les détails complexes des applications. Ces connaissances sont très difficiles à retrouver et lorsque ces employés sont remplacés, les applications qu'ils supportaient entrent souvent dans une phase d'instabilité et parfois même de chaos. Ainsi, alors que les éditeurs de logiciels s'intéressent à la stabilité, les développeurs de logiciels ne restent souvent chez un seul employeur que pendant quelques années.

L'une des stratégies employées par les éditeurs de logiciels pour atténuer la perte de connaissances consiste à utiliser des technologies largement utilisées et bien connues de la communauté des développeurs. L'utilisation de piles bien connues facilite la recherche de personnes qualifiées à embaucher. Cela aide également ces personnes à apprendre les tenants et les aboutissants des applications créées avec eux. Les développeurs peuvent être des influenceurs dans la décision des technologies à utiliser pour un projet, mais ce sont généralement les ingénieurs seniors ou même la direction qui décident des piles en utilisant ces critères. La commercialisation des outils LC/NC auprès des développeurs peut donc rater la cible.

Parier sur un outil est risqué

Les clients ont tendance à être difficiles à déterminer où ils pourraient présenter une demande à l'avenir. C'est compréhensible puisque l'avenir est très difficile à prédire. Ainsi, les propriétaires d'applications doivent s'adapter à l'évolution des besoins pour assurer le succès commercial d'une application. Cela signifie souvent modifier les modèles commerciaux et changer les technologies qui permettent de tels modèles. Les développeurs expérimentés le savent et aiment construire des systèmes ouverts qui peuvent être adaptés à l'évolution des besoins à l'avenir. La meilleure façon de créer de tels systèmes adaptables est de les coder à l'aide de langages et de frameworks bien pris en charge.

De nombreux outils LC/NC sont nouveaux, immatures et présentent des limitations techniques importantes. Ces limites ne sont généralement pas annoncées et souvent aussi peu documentées. La seule façon pour les éditeurs de logiciels de vraiment trouver ces limites est d'essayer un outil et de créer une véritable application. La plupart des limitations ne deviendront apparentes qu'après un investissement important en temps et en efforts. Le développement de logiciels est coûteux et risqué, et ces inconnues augmentent encore le risque pour les développeurs, les éditeurs de logiciels et leurs clients.

Les blocages scellent l'affaire

De nombreuses plates-formes ne permettent pas d'exporter les applications créées dans cette plate-forme vers des formats génériques modifiables. Ils verrouillent les applications, ce qui lie le développeur à la plate-forme ou l'oblige à reconstruire son application à partir de zéro. Considérant que les exigences futures sont incertaines et que les limites des outils LC/NC restent souvent cachées jusqu'à la fin du projet, il n'est pas surprenant que les développeurs puissent être extrêmement réticents à s'enfermer.

LC/NC a échoué plusieurs fois dans le passé

Les outils de développement visuel ne sont pas nouveaux. Les premières tentatives de développement visuel ont déjà été faites il y a 50 ans. Depuis lors, une pléthore d'environnements et de plates-formes de développement visuel bons et mauvais sont apparus et ont disparu et aucun d'entre eux n'a fait de différence significative dans la façon dont les applications sont créées.

Quiconque a parié sur l'un de ces outils, investi du temps et de l'énergie dans leur apprentissage et convaincu des clients de construire leurs projets dans l'un d'eux a perdu ce pari. Cette histoire suggère qu'il est peu probable que l'un des outils que nous rencontrons aujourd'hui existe encore dans une décennie. De nombreux développeurs peuvent examiner attentivement ces faits et décider que LC/NC est une impasse.

Maintenant quoi?

Alors, LC/NC est-il une cause perdue, et n'y a-t-il pas de place pour LC/NC dans le monde du développement logiciel sérieux ? Les fabricants d'outils LC/NC peuvent-ils d'une manière ou d'une autre surmonter ces obstacles et motiver davantage de développeurs à utiliser les produits LC/NC ?

De nombreux développeurs préfèrent le code en raison d'un manque de confiance dans les outils LC/NC et la communication marketing qui en fait la publicité. Pour convaincre tout professionnel d'utiliser une plate-forme LC/NC, les fabricants de plate-forme exigent que les développeurs leur fassent confiance. Pour établir cette confiance, les fabricants d'outils feraient bien d'écouter les préoccupations des développeurs et des éditeurs de logiciels et d'en tenir compte lors de la planification des fonctionnalités de la plate-forme et lors de la communication avec les groupes cibles.

La divulgation honnête et véridique des limitations fonctionnelles, la publication de moyens de surmonter les limitations, l'aplatissement de la courbe d'apprentissage des plates-formes et la possibilité d'exporter des applications vers des formats modifiables sont, même si elles ne convainquent pas tous les développeurs, des pas dans la bonne direction.