DEV Community: Alexandre Beaugrand

Code Ergonomics : 5 tendances qui simplifieront le dev.

Alexandre Beaugrand — Wed, 25 Nov 2020 10:54:58 +0000

Version Française / English version here

Prévisions sur l’évolution du développement , basées sur TRIZ

Les Lois d’évolutions de TRIZ expliquent que le développement va se simplifier et tendre vers un idéal. En m’inspirant de cette méthode d’innovation, je pense que cette simplification se fera par 2 moyens principaux, déclinés en 5 tendances.

Simplification par réduction des erreurs

visualisation ergonomique
abstraction

Simplification par réduction des tâches à accomplir

unification
automatisation
délégation

Je vous propose de détailler ces 5 tendances et de voir en quoi elles nous permettent d’imaginer l’évolution du développement. A titre d’exemple, je vous proposerais d’imaginer l’évolution des tests unitaires.

Visualisation ergonomique

Visualisation ergonomique = user-friendly

Linux est gratuit, open-source, rapide, et secure comparé à Windows ou OSX qui pourtant sont bien plus populaires pour les utilisateurs lambda.

Ce n’est pas un hasard. Une interface graphique bien pensée est plus compréhensible, plus mémorisable, plus intuitive et donne une bonne vue d’ensemble des opérations possibles. Windows et OSX sont bien plus visuellement ergonomiques, plus user-friendly, et plus compatibles *que Linux, qu’il soit utilisé en ligne de commande ou en GUI. **Leur interface graphique bien pensée les rend tout simplement *plus simples *à utiliser*, ce qui est le nerf de la guerre dans l’adoption d’un techno, surtout par des non-techs.

A l’inverse, la CLI nécessite la plupart du temps un apprentissage, et/ou une doc de référence, et n’est pas intuitive. Oui, elle est utile dans certains cas, voire incontournable pour certaines opérations qui sont bien plus rapides à faire avec une bonne ligne de commande plutôt que par une interface. Mais je suis convaincu que trop souvent, la CLI n’est pas le bon choix, et relève d’une implémentation de fonctionnalité qui n’a pas été jusqu’au bout : il manque un layer graphique.

Visualisation ergonomique = moins d’erreurs

**Par ailleurs, une interface graphique permet d’éviter les erreurs qui pourraient être commises via du code ou via une ligne de commande. **Cela est dû au fait qu’elles peuvent facilement contraindre les actions ou les options possibles. On le voit par exemple au travers des applications No ou LowCode. Dans bubble.io, si nous assignons une action à un bouton, ça ressemble à ça :

bubble.io

Il y a une liste déroulante qui permet de choisir le type d’évènement à détecter (clic). Plusieurs autres qui permettent de choisir les actions à réaliser (identifier, envoyer un e-mail, rediriger vers l’accueil). *Non seulement c’est intuitif, mais ces listes déroulantes, contrairement au code, empêchent les erreurs de syntaxes, l’appel de fonctions inadéquates, ou le passages de paramètres incohérents. *

Visualisation ergonomique = gain de temps

Les interfaces user-friendly font également gagner du temps. Elles pourront même en faire gagner aux devs, et ce même s’ils pourraient s’en passer car ils ont la capacité d’apprendre la CLI ou les langages.

Car là n’est pas la question : nous cherchons à savoir ce qui est le plus efficace pour maitriser une API en partant de 0. Si vous êtes un virtuose du shell ou de la CLI d’un framework, je ne doute pas dans ce cas que vous pouvez faire les choses rapidement.

Mais vous avez dû apprendre ces commandes, ce qui représente un coût non-négligeable en termes de temps. Et lorsque nous parlons de Code Ergonomy, nous cherchons à réduire ce coût. Hors une API inconnue est bien plus rapide à maitriser lorsqu’elle est visuelle que lorsque elle est utilisable par du code ou par une CLI.

Prenons l’exemple de la mise en place d’un environnement de développement. A l’heure actuelle, on peut utiliser une première ligne de commande pour cloner un projet git, ou pour lancer la création d’un projet type. Il faut ensuite lancer une nouvelle commande pour lancer l’importation des modules. Puis en lancer une autre pour servir le projet, avec entre temps une possible modification de webpack ou autre bundler afin de coller à nos exigences en termes de transpilation, de linting, de hot-reloading, etc. Dans codesandbox.io, tout cela est visuel, et nécessite 3 clics. Bref, on gagne du temps.

configuration de l’environnement avec codesandbox.io

Est-ce aux devs de réaliser des UI efficaces ?

Ce n’est pas l’idéal, mais lorsque l’on travaille sur un projet solo ou dans une petite équipe qui n’a pas de graphiste ou d’expert UX, les devs sont amenés à concevoir des interfaces bien pensées.

Trop souvent pourtant, ils ont tendance à négliger l’ergonomie visuelle, considérant que ce n’est pas de leur ressort et que leur valeur-ajoutée réside dans la mise en place de fonctionnalités. Il y a un cloisonnement inopportun entre ce qui relève de ingénierie et ce qui relève du graphisme.

Pourtant, **à la Renaissance, il n’y avait pas de cloisonnement entre ce qui relevait de la Science ou de l’Art. On cherchait à être complet. **Je pense donc que les devs gagneraient à se confronter à l’exercice de création d’une UI efficace et bien pensée.

Léonard De Vinci : scientifique, ingénieur, inventeur, anatomiste, peintre, sculpteur, architecte, urbaniste, botaniste, musicien, poète, philosophe et écrivain

Abstraction

Utiliser un langage de haut-niveau, et séparer la description d’une application métier, de son moteur, permet de bénéficier des évolutions permanentes des patterns et syntaxes sans avoir à se former continuellement : car l’application reste optimisée sans avoir à être réécrite par leurs devs. Cela nécessite un article à part entière que vous trouverez ici.

Unification

Dans les lois d’évolution de TRIZ, on observe de multiples tendances. L’une d’elle concerne la fusion des composants d’un système. Voyez plutôt les tendances “Using dissimilar Elements” ou “Using Similar Elements” dans ce graphique.

Tiré de l’excellent livre Triz for Engineers de Karen Gadd, page 444.

Les multiples composants du développement vont s’unifier pour devenir un environnement de programmation tout-en-un, un peu comme Flash il y a des années (bien qu’il manquait le côté serveur), Meteor, Unreal Engine, ou Unity.

Unreal engine

*Il y aura ainsi une fusion des multiples outils utilisés aujourd’hui séparément : bundler, gestionnaire de modules, versioning, transpiler, CLI, etc. Tout sera intégré dans l’éditeur de code, le plus souvent sous forme d’options, de paramètres, et de menus. *

Là encore, on le voit bien dans codesandbox.io ainsi que dans visual studio code qui intègre un terminal, une console de debug, et toutes sortes de modules.

Visual Studio Code

La loi d’évolution n°6 de TRIZ — Transition vers le super système, spécifie également qu’un système devient une partie de son super-système, c’est à dire de son environnement.

Ainsi l’environnement de programmation (système) sera intégré au cloud (super-système). Il n’y aura donc plus non-plus de séparation local / distant. Tout sera en ligne.

On le voit déjà avec CodeSpaces de GitHub (encore en version beta) qui est un environnement de développement intégré au cloud :

Codespaces

Automatisation

C’est surement le point le plus important. Grâce à l’automatisation, moins, voir plus du tout de configuration.

Plus de configuration d’environnement

A la manière de codesandbox ou grâce au tree-shaking de parceljs, capable de s’autoconfigurer en analysant lui même le code source et les dépendances d’un projet.

Plus de configuration du versioning

Utiliser la ligne de commande peut être amélioré. Les sauvegardes peuvent être partiellement automatisées, un peu comme les sauvegardes incrémentielles de Synology Cloud Backup ou dans la TimeMachine d’Apple :

Apple Time Machine permet de parcourir la frise du temps à droite et de retrouver l’état d’un projet passé par de multiples fenêtres superposées

J’ouvre une parenthèse pour préciser que visuellement, le versioning pourrait s’inspirer du gestionnaire d’historique de Wordpress ou de la suite Adobe, mais avec les capacités de forks, de merge et autres subtilités de git. Il y a beaucoup de possibilité d’évolutions, mais en attendant, des outils comme Git Kraken ou Git Tower proposent un UI améliorée.

Git Kraken

Plus de configuration du cloud ni de déploiements fastidieux

A la manière de softaculous, qui permet de mettre en place ou de cloner un Wordpress ou autre système en un clic, les clouds pourraient être automatisés.

Softaculous

**Les hébergeur pourraient techniquement détecter le boilerplate et les fichiers de configuration de nos projets, en déduire toutes les dépendances, les mettre en place et les configurer. **Après tout nous disions que Parcel est capable de le faire pour les environnements de dev.

Par ailleurs, le déploiement pourraient se faire via un bouton [Déployer] dans l’IDE. Voir Codespaces.

Les services de Cloud ont encore de larges possibilités d’évolutions, car ils ne se sont pas assez adaptés aux nouvelles pratiques du développement front. Ils devraient s’automatiser car cela rendrait un vrai service aux développeurs, qui sont leurs utilisateurs et clients typiques. Ils amélioreraient ainsi considérablement leurs parts de marché.

Plus de programmation des tests unitaires

Au-delà du débat sur l’utilité des tests unitaires, dont nous nous sommes passés pendant des dizaines d’années alors que beaucoup d’applications restaient de bonne qualité (de part les tests utilisateurs), nous sommes encore trop bas niveau quand nous les écrivons.

**Ces tests pourraient être partiellement automatisés. **J’aborderais ce cas plus en détail dans la dernière partie de cet article.

Mais surtout : moins, voir pas du tout, de code

*L’app pourrait être décrite soit par un langage de haut-niveau, soit visuellement, et traduite par un moteur d’interprétation. *

On peut encore citer ici les plateformes No ou Low code. L’exemple le plus parlant à mon sens est encore bubble.io qui reste très flexible et n’est pas cantonné à la création de sites web vitrines comme beaucoup pourraient le penser. Testez donc le tutoriels de 5min pour en avoir une idée.

Cette séparation Description / Moteur est la condition pour une automatisation efficace. On la trouve dans les SGBD, avec le SQL qui peut être combiné aux moteurs MyISAM ou InnoDB par exemple.

Il y a beaucoup de chose à dire à ce sujet, que je traite avec l’Abstraction, dans cet article.

Délégation

Actuellement les devs s’occupent a peu de tout : de l’architecture, de la configuration de l’environnement, du développement, des tests, du débogage, du versioning, de la configuration serveur, et des mises en ligne. Comment tout maitriser ? Peut-on être spécialiste en tout ? Acceptons-nous d’être spécialisé en rien ? Ou peut faire plus optimisé ?

*Les tâches qui incombent aux développeurs vont se réduire : ce qui ne pourra être automatisé sera simplifié. Ce qui ne pourra pas non plus être simplifié sera confié à des spécialistes. *

Je pense particulièrement à ce qui relève de la gestion du cloud, dont j’ai parlé plus haut : si un hébergeur offre un déploiement *réellement *en un clic, adapté aux architectures les plus courantes, il remportera de nombreuses parts de marché.

Par ailleurs, au sein même de la communauté dev., je pense qu’une distinction entre les dev. créateurs d’application et les dev. créateurs d’outils sera nécessaire, afin de se spécialiser dans l’apprentissage de ce qui nous est réellement utile. Pour ne pas me répéter, je vous invite de nouveau à lire cet article pour plus de détails.

Exemple : évolution des tests unitaires

Essayons de voir à travers cet exemple comment ces 5 tendances nous permettent d’imaginer l’évolution des tests unitaires.

Le problème

Le problème, c’est qu’en plus d’être rébarbative, l’écriture des tests unitaires double grosso-modo le temps et donc le coût de développement.

Axe d’évolution, à partir des 5 principes

Les tests seraient intégrés à l’IDE qui pourrait auto-tester un projet (unification *des composants et *délégation *des tests à l’IDE) en appuyant sur un bouton plutôt que par une CLI (*abstraction, visualisation).

L’IDE testerait automatiquement (automatisation), pour chaque composant d’un interface, toutes les évènements possibles (un bouton serait cliqué, double-cliqué, survolé, tandis ce qu’un formulaire serait envoyé, remis à zéro, etc.). Les réactions aux évènements seraient analysées et cela permettrait de mettre en valeur les incohérences ou conflits de l’application.

Par exemple, l’IDE pourrait se rendre compte qu’une même fonction serait invoquée plusieurs fois mais avec des arguments de types différents, ou bien qu’elle retournerait des valeurs de types différents.

Il en résulterait alors une liste de ces incohérences trouvées dans une interface (visualisation), qui nous proposerait de trancher sur l’input ou l’output réellement attendu. Cela se rapprocherait de GitKraken lorsqu’il nous demande de trancher lors d’un merge conflict, mais ici, le choix se ferait le plus souvent au moyen de listes déroulantes.

Les résolutions de conflits permettraient ainsi de faire évoluer le fichier de configuration qu’à ce jour nous créons à la main.

Merci de m’avoir lu jusqu’ici.

Code Ergonomics : 5 trends that will simplify dev.

Alexandre Beaugrand — Wed, 25 Nov 2020 10:52:00 +0000

English version / Version Française ici

Forecasts on dev evolution, based on TRIZ

The TRIZ laws of technical systems evolution show that development will become simpler and tend towards an ideal. Inspired by this method of innovation, I believe that this simplification will be done in 2 main ways, declined in 5 trends.

Simplification by reducing errors

ergonomic visualization
abstraction

Simplification by reducing tasks

unification
automation
delegation

I propose to detail these 5 trends and see how they allow us to foresee dev evolution. As an example, I will then forecast the evolution of unit tests.

Ergonomic visualization

Ergonomic visualization = user-friendlyness

Linux is free, open-source, fast, and secure compared to Windows or OSX which yet are much more popular for regular users.

This is no coincidence. Windows and OSX are much more visually ergonomic, more user-friendly, and more compatible than Linux, whether used as a command line or as a GUI. Their well-thought-out graphical user interface simply makes them simpler to use, which is a real asset for a tech to be adopted, especially for regular users.

On the other hand, CLI requires most of the time a learning process, and/or a reference document, and is not intuitive. Yes, it is useful in some cases, even unavoidable for some operations that are much faster to do with a good command line than with UI. But I'm convinced that too often, CLI is not the right choice, and is a feature implementation that didn't go all the way: it lacks a graphical layer.

Ergonomic visualization = less errors

Furthermore, a graphical user interface avoids errors that could be made via code or via a command line. This is due to the fact UI can easily constrain the possible actions or options. This is seen, for example, in No or LowCode apps. In bubble.io, if we assign an action to a button, it looks like this:

Bubble.io

There is a drop-down list that allows you to choose the type of event to detect (click), and several others that allow you to choose the actions to be performed (identify, send an e-mail, redirect to reception). Not only is it intuitive, but these drop-down lists, unlike code or commands, prevent syntax errors, as well as calling inappropriate functions, or passing inconsistent params.

Ergonomic visualization = time saving

User-friendly interfaces also save time. They can even save time for devs, even though they could do without UI because they have the ability to learn CLI or languages.

Because that's not the point: we are here trying to find out what is the most efficient way to master an API starting from 0. If you are a shell master frameork CLI master, then I have no doubt you can do things quickly.

But you had to learn these commands, which represents a significant cost in terms of time. And when we talk about Code Ergonomics, we are trying to reduce this cost. It turns out an unknown API is much faster to master when it is visual than when it is operable by code or by a CLI.

Let's take the example of setting up a dev environment. Currently, you can use a first command line to clone a git project, or to start creating a starter project. Then you need to run another command to start importing modules. Then another one to serve the project, with in the meantime a possible modification of webpack or other bundler config to fit our requirements in terms of transpilation, linting, hot-reloading, etc... In codesandbox.io, all this is visual, and requires 3 clicks. Simply put, we save time.

Env. setup with codesandbox.io

Is it devs job to make efficient UIs?

It's not ideal, but when working on a solo project or in a small team that doesn't have a graphic designer or UX expert, devs have to design well thought-out interfaces.

All too often, however, they tend to neglect UI ergonomics, considering that it is not their responsibility and that their added value lies in the implementation of functionalities. There is an "inappropriate partition" between engineering and graphic design.

However, in the Renaissance, there was no partition between Science or Art. People tried to be complete, to master both. So I think devs would benefit from trying to create efficient and well thought Uis.

Leonardo Da Vinci : scientist, engineer, inventor, anatomist, painter, sculptor, architect, urban planner, botanist, musician, poet, philosopher and writer

Abstraction

Using a high-level language, and separating app description from its engine, allows us to benefit from the permanent evolution of patterns and syntaxes without having to train continuously: because apps remain optimized without having to be rewritten. This matter needs its own article which you can find here.

Unification

In TRIZ's laws of technical systems evolution, there are multiple trends. One of them concerns the merging of system components. Please refer to the "Using dissimilar Elements" or "Using Similar Elements" trends in this graph.

From Karen Gadd's excellent book Triz for Engineers on page 444.

The many dev tools will unify to become an all-in-one programming environment, kind of like Flash years ago (although server-side was missing), Meteor, Unreal Engine, or Unity.

Unreal engine

This will merge the multiple tools that are currently used separately: bundler, module manager, versioning, transpiler, CLI, etc. Everything will be integrated into the code editor, most often in the form of options, parameters and menus.

Again, we can already see it in codesandbox.io as well as in visual studio code which integrates a terminal, a debug console, and all kinds of modules.

Visual Studio Code

The 6th TRIZ law of evolution - Transition to the supersystem, also specifies that a system will become part of its supersystem, i.e. its environment.

So the programming environment (system) will be integrated into the cloud (super-system). There will no longer be any local / remote separation. Everything will be online.

We already can see it with CodeSpaces from GitHub (still in beta version) which is a cloud IDE:

Codespaces

Automation

This is probably the most important point. Thanks to automation, most configs can be avoided.

No more env. config

Like codesandbox or thanks to the tree-shaking of parceljs, dev environments will be able to self-configure by analyzing projects source code and the dependencies.

No more versioning commands

Using the command line can be improved. Backups can be partially automated, similar to the incremental backups in Synology Cloud Backup or Apple's TimeMachine :

Apple Time Machine allows to browse the timeline on the right and find the past state of a project displayed through multiple overlay windows

On a side note, I'd like to specify that visually, versioning could be inspired by Wordpress or Adobe Suite's history managers, but with the added capabilities of forking, merging and other subtleties of git. There is a lot of room for improvement, but in the meantime, tools such as Git Kraken or Git Tower offer somewhat improved UIs.

Git Kraken

No more cloud configuration or tedious deployments

Like softaculous, which allows to set up or clone a Wordpress or other system project in one click, clouds could be automated.

Softaculous

**WebHosts could technically detect app boilerplates and config files, deduce all dependencies, auto-load them and set them up. **After all, we mentioned Parcel is already able to do this for dev environments.

In addition, easy deployment could be done via a single Deploy button in the IDE. Like in Codespaces.

Cloud services still have a lot of room for evolution, as they didn't adapt well to the new practices of front-end development. They should be automated, as this would provide a real service to developers, who are their typical users and customers. They would thus considerably improve their market share.

No more unit tests programming

Beyond the debate on the usefulness of unit testing, which we didn't have to deal with for decades while many applications were still of high-quality (thanks to user testing), we are still too low-level when we code them.

These tests could be partially automated as well. I will discuss this case in more detail in the last part of this article.

But above all: less, or not at all, code.

Apps could be described either through a high-level language or visually. Then this description could be translated by an interpretation engine.

Here we can also refer to No or Low-code platforms. The best example in my opinion is still bubble.io which is very flexible and not only limited to the creation of showcase websites as many might think. I invite you to try their 5min tutorials to get an idea of its flexibility.

This Description / Engine separation is the prerequisite for efficient automation. It can be found, for example, in DBMS, with SQL that can be combined with the MyISAM or InnoDB engines.

There is much to be said on this matter, which I approach along with Abstraction, in this article.

Delegation

Currently devs are taking care of almost everything: architecture, environment configuration, development, testing, debugging, versioning, server configuration, and online releases. How can they master everything? Is it possible to become a specialist in all those matters? Do we accept not to be specialized in anything? Or can we make changes to optimize this situation?

Devs tasks will be reduced: what can't be automated will be simplified. What can't be simplified will be left to specialists.

I'm particularly thinking about cloud management, which I mentioned earlier: if a webhost offers a real one-click deployment, adapted to the most common project architectures and framework, he will win a lot of market share.

Last but not least, within the dev. community itself, I think that a distinction between devs who make apps vs devs who make devtools will be necessary, in order for them to specialize and learn what is actually useful regarding their needs. I'd like to avoid repeating myself, so I invite you to read this article for more details.

Example: unit testing evolution

Let's try to see through this example how these 5 trends allow us to imagine the evolution of unit testing.

The problem

In addition to being boring, writing unit tests roughly doubles the time and therefore the cost of development.

Possibilities of evolution, based on the 5 principles

Tests would be integrated into the IDE, which would be able to self-test a project (unification of components and delegation of tests to the IDE) by pressing a button rather than by a CLI (abstraction, visualization).

The IDE would automatically test (automation), for each UI component, all possible events (a button would be clicked, double-clicked, hovered, while a form would be sent, reset, etc.). The reactions to those events would be analyzed and this would highlight any inconsistencies or conflicts in the application.

For example, the IDE might show that the same function is invoked several times but with arguments of different types, or that its return values are of different types.

The result would then be a list of these inconsistencies, display in an interface (visualization), which would ask us to decide on the input/output really expected. This would be similar to GitKraken when it asks us to decide on a merge conflict, but here, the choice would most often be made though simple drop-down lists.

Conflict resolution would thus automatically apply changes to the tests description files we currently create by hand.

Thank you for reading me this far.

Les développeurs n’auront plus à optimiser leurs applications

Alexandre Beaugrand — Mon, 23 Nov 2020 15:58:04 +0000

Version Française / English version here

Les bénéfices de l’Abstraction

Dans cet article, j’expliquerai pourquoi les développeurs n’ont pas besoin d’optimiser leurs applications. Cela est lié au fait que le développement Web va évoluer pour devenir plus simple, par l’Abstraction.

Je commencerais par comparer les évolutions des voitures et des outils de développement, avant d’expliquer pourquoi je pense que nous nous faisons fausse route.

Je proposerais ensuite un moyen de résoudre les problèmes lié au développement web moderne, en reconsidérant les rôles des développeurs et la structure du code source.

Je conclurais enfin en abordant une nouvelle façon d’utiliser les frameworks modernes. J’espère que mon idée vous paraitra pertinente.

Comparons l’évolution des voitures et des outils de développement

Établissons un parallèle entre l’évolution de la voiture et l’évolution du développement.

L’évolution de la voiture

Les voitures ont évolué. Elles sont devenues plus rapides, plus sûres, moins consommatrices, moins polluantes. On peut dire qu’elles ont été optimisées. Est-ce que l’utilisation de ces voitures à évolué ?

Non, ou très peu. Un conducteur de voiture en 2020 conduit grosso modo comme un conducteur en 1940.

Il n’a pas besoin de savoir comment gagner en vitesse, sécurité, consommation, ou écologie. C’est la voiture qu’il utilise qui s’en occupe. Des spécialistes ont travaillé sur le sujet et l’on optimisée. Il n’y a pas besoin de savoir comment ça marche pour profiter de ses performances.

L’évolution des langages et des outils de développement

Les langages et outils de développement ont, eux aussi, évolués. Ils permettent de créer des apps plus rapides, plus sûres, moins lourdes, plus fiables, responsives, etc. On peut dire qu’ils ont été optimisés. Est-ce que l’UTILISATION de ces outils et langages à évolué ?

Drastiquement. Un développeur front-end des années 2000 avait simplement besoin de connaitre le HTML et le CSS. Il n’avait aucunement besoin de maitriser un framework JS, de paramétrer un environnement Node, de configurer Webpack, de savoir ce que sont les promises, les immutables, les observables, les design patterns, les appels API, la délégation d’évènements, le hoisting, ou de réaliser des tests unitaires ou fonctionnels.

En 2020, il faut maitriser ces concepts, sous peine de ne pas développer avec les dernières techs tendances et risquer d’être considéré comme quelqu’un créant des applications sous-optimisées.

Nous faisons fausse route

Pourquoi note t’on une telle différence entre l’évolution de la voiture et celle des outils de développement ?

Utilisateurs de voitures

Dans le cas de la voiture, l’utilisateur de la voiture est clairement identifié (M. Tout le monde) et séparé des différent des concepteurs de la voiture (ingénieurs, mécaniciens, designers, etc.).

Il est clair qu’il n’est pas concevable d’attendre de l’utilisateur qu’il connaisse comment ça marche pour pouvoir bénéficier de l’optimisation de la voiture.

Utilisateurs des outils de développement

Dans le cas des outils de création d’applications, les utilisateurs et les concepteurs de ces outils sont tous des développeurs.

Ainsi, il semble naturellement beaucoup plus concevable d’attendre des utilisateurs de ces outils qu’ils comprennent leur fonctionnement, et qu’ils adoptent les bonnes pratiques de codage permettant de favoriser travail d’équipe, maintenabilité, et optimisation.

C’est pourquoi actuellement, la maitrise d’un framework nécessite un long apprentissage : sa mise en place et son boilerplate doivent être démystifiés, les opérations possibles via sa CLI comprises, son organisation et ses design patterns clarifiés. Il faut aussi comprendre quelles sont les principales classes / fonctions utilisées, et quels concepts clés il est nécessaire d’adopter (l’état doit être immuable, le fonctions doivent être pures, etc.).

Ce qui cloche dans le développement moderne

Demander aux utilisateurs d’outils de développement de comprendre des concepts en constante évolution, c’est comme attendre d’un utilisateur de voiture qu’il comprenne de quel type de caoutchouc ses pneus sont faits pour être plus sûrs, quelles fréquences ses radars de stationnement utilisent, ou comment fonctionne l’injection de carburant.

Cela doit rester sous le capot, même si l’utilisateur de la voiture s’avère être un ingénieur et serait capable de comprendre. Car prendre le temps nécessaire pour comprendre a un coût en termes d’efforts, de temps de formation, de temps de pratique, de temps de débogage, et donc de coût de développement.

Il est donc sous-optimal d’attendre des utilisateurs d’outils de développement qu’ils acquièrent toutes ces connaissances afin de favoriser le travail d’équipe, la maintenabilité, et l’optimisation de leurs applications.

Comme pour les concepteurs automobiles, la maîtrise de ces concepts devrait rester l’affaire d’un type particulier de développeurs spécialisés dans la conception d’outils de développement.

2 nouveaux types de développeurs

Au lieu d’un distingo dev. front / dev. back (qui a de moins en moins de sens), je vous propose d’imaginer un distingo dev. utilisateur d’outils / dev. concepteur d’outils.

Développeur utilisateur d’outils

Le développeur utilisateur d’outils à pour mission de créer des sites et applications en suivant un cahier des charges. Il sait réaliser une interface et décrit les composants, les fonctionnalités, et les interactions de l’application.

Développeur concepteur d’outils

Le développeur concepteur d’outils est un spécialiste maitrisant les structures de code les plus optimisées, les designs patterns les plus pertinents pour résoudre un problème donné. Il est en charge de créer et de faire évoluer des outils de développement permettant de réaliser les même fonctions (détections d’évènements, modification de l’interface, sauvegarde, authentification, etc.), mais de manière toujours plus performante.

Application vs moteur

Il est possible de créer des applications qui facilitent le travail d’équipe, sont optimisées et maintenables, sans avoir à maîtriser les meilleurs pratiques et les concepts de programmation toujours plus nombreux. Nous pouvons y parvenir en séparant l’application du moteur.

Application

Les développeurs utilisateurs d’outils de développement ne doivent s’occuper que de la description de leurs applications (fonctionnalités, interactions, composants, interface utilisateur).

Une façon de le faire serait de décrire les applications visuellement. Les applications NoCode telles que bubble.io proposent de le faire, puis de traduire la description visuelle de chaque application en une véritable application. De nombreux développeurs pensent que ces outils offrent des possibilités limitées, mais je vous suggère d’essayer leurs tutoriels de 5 minutes pour voir quelle flexibilité vous pouvez obtenir.

Exemple d’application descriptive : bubble.io

Une autre façon de procéder serait d’utiliser un langage haut-niveau qui ressemblerait à des spécifications fonctionnelles, mais qui décrirait l’application d’une manière beaucoup plus programmatique (donc structurée).

Par exemple : Il existe la possibilité d’ identifier l’utilisateur via [e-mail/ mot de passe / empreinte digitale / rétine / etc.] matérialisé par [une boîte de connexion avec 2 champs / un appareil / etc.] Cette boîte utilisera [des enregistrements en base / des enregistrements en fichiers / etc.] En cas de succès, nous [accéderons à une page / ajouterons une entrée en base de données / enverrons un e-mail / etc.]

Ce langage serait écrit dans un seul outil de développement, qui serait configuré pour utiliser un moteur d’optimisation parmi d’autres. Pour la fonctionnalité d’ identification de l’utilisateur , chaque moteur offrirait de nombreuses options concernant, par exemple, les entrées [e-mail / mot de passe / emprunte digitale / rétine / etc.], l’affichage [une boîte de connexion de 2 champs / un appareil / etc.], les relations [enregistrements dans la base de données / enregistrements dans le fichier / etc.], ou les actions de sortie [accès à une page / ajout d’une base de données de connexion / envoi d’un e-mail / etc.]

Moteur

Les développeurs concepteurs d’outils travailleraient en fait sur les moteurs. Ils seraient chargés de traduire les descriptions des applications en un code optimisé, bien structuré, bien testé et sans bogue. De temps en temps, il y aurait une mise à jour d’un moteur, pour des performances toujours meilleures. Chaque mise à jour ne casserait rien car les moteurs seraient totalement indépendants des descriptions d’applications.

Pour avoir une idée de la façon dont cela fonctionnerait, vous pouvez penser à ce qui s’est passé avec PHP, puisque son noyau a été remanié à plusieurs reprises. PHP7 est par exemple beaucoup plus rapide que ses prédécesseurs, mais en tant que développeur PHP, vous n’avez pas besoin de comprendre ou de vous soucier de ce qui a changé en interne. La nouvelle version permet de meilleures performances, même si vous conservez le même code d’application. C’est tout ce que vous avez besoin de savoir.

Vous pouvez également penser aux bases de données relationnelles, où la séparation entre l’application et le moteur existe déjà. Les moteurs MyISAM, ou InnoDB, offrent des différences tout en étant liés au même langage SQL.

Les frameworks pourraient devenir des moteurs

La plupart des frameworks sont le résultat d’un travail de qualité, compte-tenu des nombreux spécialistes qui ont participé à leur élaboration. Par conséquent, ne pas utiliser ces outils serait un gaspillage. Cependant je pense qu’attendre des développeurs utilisateurs d’outils de maîtriser autant de concepts afin de faire fonctionner ces frameworks est sous-optimisé.

Lorsque vous vous documentez sur un nouveau framework, vous tombez rapidement sur la section “Pourquoi ce framework ?”. La plupart de ces outils mettent l’accent sur leur faible poids, leur réactivité, etc. Si ces caractéristiques sont certainement pertinentes pour les moteurs d’applications, les frameworks manquent cruellement, en revanche, de facilité d’utilisation (même si certains prétendent être simples). Ils sont trop bas niveau, ce qui, à mon avis, n’en fait pas de bons candidats comme outils de description d’applications.

Comme nous devrions séparer les outils de description des applications, et les moteurs, nous pouvons imaginer que le même code source de description des applications permettrait de générer des applications de divers types (ou frameworks).

Par exemple, il permettrait de générer des applications en React, Angular, ou Vue. Ou bien encore des applications en Laravel ou Ruby. Tous les frameworks deviendraient des moteurs interchangeables car leur code serait généré en fonction du choix du développeur utilisateur d’outils.

Ce concept est proche des apps hybrides. Par exemple, PhoneGap ou Ionic sont capables, avec presque le même code de base, de générer des applications Android ou iOs.

PhoneGap utilise Cordova pour générer des apps Android, iOs, etc. en utilisant HTML/CSS/JS

Pour conclure

Les lois de l’évolution TRIZ expliquent que tout système tend vers un idéal, ce qui signifie moins de coûts. La cinquième loi d’évolution indique également que les systèmes augmentent d’abord en complexité avant de se simplifier.

Le développement d’applications a déjà augmenté en complexité. Il est maintenant temps de le simplifier. Ce que je propose dans cet article est une réponse à ce besoin de simplicité.

Si les rôles des développeurs sont redéfinis, si les applications sont séparées de leurs moteurs, et si nous utilisons un langage très haut-niveau pour décrire les applications, nous obtiendrons une plus grande efficacité.

Et pour chaque nouvelle mise à jour d’un outil ou d’un framework, il n’y aurait plus de coûts d’apprentissage. Juste un pop-up dans l’outil de développement.

Avec un bouton : [mettre à jour le moteur].

La curieux lien entre Simplicité et Performance

Alexandre Beaugrand — Mon, 23 Nov 2020 15:55:28 +0000

Version Française / English version here

Ce que les développeurs peuvent apprendre des géants

2009, Berlin : Usain Bolt bat le record du monde du 100m hommes en 9,58 secondes. Voyez comme cela parait simple, pour lui :

2012, Pékin : Lang Lang joue La Campanella. Cela a l'air si simple pour lui qu'on dirait qu'il s'amuse :

Malgré la complexité sous-jacente de ces métiers, malgré tout le temps et les efforts qui ont été nécessaires pour atteindre le niveau maximal, lorsque l'on regarde leur manière d'être et de faire, cela parait simple.

Trop souvent, on pense que ce qui semble simple n'est pas optimisé

Bien avant mes premiers articles sur la simplication du développement, j'ai eu de nombreuses discussions avec des développeurs maîtrisant les complexes frameworks actuels que sont Angular ou React, ainsi que leurs outils d'environnement associés.

*Souvent, mes interlocuteurs n'étaient pas d'accord sur le fait que le *développement devrait devenir et deviendra simple. **Pour eux, la maîtrise de la technologie est naturellement complexe et le restera.

Ils disaient que cela faisait partie de notre travail, en tant que devs, d'apprendre continuellement afin de rester à jour sur les dernières évolutions techniques. C'est ainsi que les applications peuvent évoluer et continuer à être optimisées.

La plupart d'entre eux n'ont pas ressenti le besoin d'avoir des outils ou des frameworks simples. Car c'est à nous de nous adapter. Nous devons nous former continuellement. Parce qu'en tant que développeurs ou ingénieurs, nous en sommes capables.

Le code le plus optimisé est un code simple

Usain Bolt et Lang Lang ont atteint le sommet de leurs domaines respectifs.

Quand Usain Bolt court, ça semble simple, mais ça ne l'est pas. Quand Lang Lang joue, ça semble simple, mais ça ne l'est pas. Sous le capot, il y a des milliers d'heures d'apprentissage et d'entrainement complexe.

Il est possible d'imaginer des outils de développement simples et de haut niveau, qui nous permettraient d'atteindre des performances optimales en générant les applications les plus performantes. Des outils de premier ordre qui semblent simples, mais qui ne le sont pas. Des outils que nous pouvons utiliser de façon simple, mais qui sont performants en raison de leur complexité sous-jacente.

C'est possible, par exemple, si nous utilisons l'abstraction et si nous séparons la description d'une application, de son moteur.

Vous n'êtes pas un mauvais développeur si vous préférez les syntaxes et patterns simples, lisibles, et de haut-niveau, au lieu de syntaxes et patterns certes à la mode mais confus ou complexes. Parce que si les outils étaient bien pensés, ils pourraient offrir à la fois simplicité et performance. C'est techniquement possible.

Outre l'optimisation, simplicité signifie meilleure lisibilité, meilleure maintenance, meilleure évolutivité, meilleur travail d'équipe, moins de temps de formation et donc moins de coût global de développement.

Et la Simplicité apporte quelque chose de plus.
Quelque chose que vous trouverez dans la façon d'être des gens simples.
Quelque chose que vous trouverez dans de rares démonstrations mathématiques.
Quelque chose que vous trouverez dans la programmation, la science, la mode ou le design.
Elle apporte l'Élégance.

The curious relationship between simplicity and top-performance

Alexandre Beaugrand — Sat, 21 Nov 2020 10:39:51 +0000

English version / Version Française ici

What devs can learn from Giants.

2009, Berlin: Usain Bolt beat the 100m Mens World Record in 9.58 seconds. Please take a look at how simple it seemed for him:

2012, Beijing: Lang Lang plays La Campanella. It looks so simple for him it actually looks like he is playing around:

Despite the underlying complexity of these crafts, despite all the time and efforts that have been required to reach their top level, when you take a look at the way they do stuff, it actually looks simple.

Too often, we think that what looks simple isn't optimized

Long before my first articles on Dev. Simplicity, I had many talks with devs who master current complex modern frameworks such as Angular or React, as well as their related environment tools.

Most of the time, they didn’t agree that development will and should become simple. To them, mastering tech is naturally complex and it should stay this way.

They were saying it is part of our job to keep learning stuff in order to keep up with modern tech evolutions. Because this is how apps can evolve and can keep being optimized.

Most of them didn’t feel the need for tools or frameworks to become simple. We should adapt. We should learn. Because as devs or as engineers we can.

Top-level code is simple code

Usain Bolt and Lang Lang reached the top-level of their fields.

When Usain Bolt runs, it looks simple, but it’s not. When Lang Lang plays, it looks simple, but it’s not. Under the hood, it has been very complex for them as they’ve been learning and training for thousands of hours.

It is possible to imagine simple, top-level dev tools, that would allow us to reach top-performance as well, by generating the most optimized apps. First-class tools that look simple, but which are not. Tools that we can operate in a simple way, but which are performant because of their underlying complexity.

Their complexity should stay under the hood, and most devs should not have to deal with it. It is possible, for example, if we use abstraction and if we separate app description from app engine.

You are not a bad developper for prefering simple, highly-abstracted and readable syntaxes and patterns, over overly-complex and mystified trendy syntaxes and patterns. Because if tools were well-thought, they could offer both simplicity and performance. It is technically possible.

And besides optimization, Simplicity means better readability, better maintainance, better evolutivity, better teamwork, less training time, and less overall development cost.

But it also leads to something more.
Something you’ll find in simple people’s way-of-being.
Something you’ll find in rare mathematical demonstrations.
Something you’ll find in programming, in science, in fashion, or in design.
It leads to Elegance.

Le développement va se simplifier

Alexandre Beaugrand — Sat, 14 Nov 2020 08:49:11 +0000

Version Française / English version here

Développeur et formateur web depuis une quinzaine d’années, je n’ai pas été épargné par la “Javascript Fatigue”. Ma recherche d’une “cure” à cette fatigue, m’a amené à réfléchir aux absurdités de la programmation, et à l’environnement de programmation idéal.

J’aimerais, dans cet article introductif, vous exposer ce dont je suis persuadé : le développement va se simplifier. Par la suite, je préparerais une série d’articles décrivant en détail les raisons de mon opinion. Cela vous permettra je l’espère, d’entrevoir à quoi ressembleront les prochains environnements de développement, ainsi que la programmation web.

Mes propos s’inspirent de TRIZ

Imaginer l’avenir, c’est plus facile en se basant sur une méthode. A plusieurs reprise, je ferai référence à TRIZ, une méthode soviétique dont je me suis inspiré, permettant à la fois de résoudre des problèmes d’innovation, et d’innover en prévoyant l’évolution des technologies.

TRIZ à fait ses preuves : à titre d’exemple, Samsung l’utilise depuis des années et elle lui a permit de déposer bon nombre de brevets. Par ailleurs, cette méthode est enseignée dès l’école en Corée du Sud, pays on ne peut plus innovant.

TRIZ comprend de multiples concepts et outils auxquels je ferai référence dans mes articles. Je me réfèrerai principalement aux Lois d’évolutions des systèmes techniques, et au Diagramme 9 écrans.

Le développement va tendre vers un idéal

La première chose à savoir, d’après la Loi d’évolution N°4 — Accroissement de l’idéalité, c’est que les outils de programmation, comme tout système, vont tendre vers un idéal. L’idéal, au sens de TRIZ, est définit ainsi :

Un système est idéal s’il offre un maximum de bénéfices, sans coût, et sans effets néfastes.

Cette équation simple remet donc en question une croyance répandue auprès de nombreux développeurs, selon laquelle si les outils actuels permettent de créer des applications plus sûres, plus fiables, plus orientées travail en équipe, plus évolutives, et plus réactives, il faudrait absolument les utiliser.

Ce sont en effet de nombreux bénéfices qu’apportent les outils et frameworks modernes. Sauf que l’idéal n’est pas atteint pour une raison simple :

Les outils et frameworks actuels ont un coût et des effets néfastes

Ne le pensez-vous pas ? En voici une liste non-exhaustive :

confusion dans les choix techniques due à la multiplication d’outils concurrents (frameworks, librairies, et outils/modules des environnements)
manque de pérennité des applications, due à ces choix techniques incertains, ainsi qu’aux changements fréquents des syntaxes, et des bonnes pratiques
nécessité de posséder de nombreuses connaissances et de se former continuellement afin de maitriser les bonnes pratiques nécessaires à la production d’une application ad-hoc structurée, sécurisée, testée, et optimisée
difficulté pour recruter des profils de développeurs à la fois experts et polyvalents, et difficulté pour trouver des missions pour les développeurs non-aguerris aux technos tendances
augmentation du temps de production dus à l’augmentation générale du temps de formation, de paramétrage de l’environnement, du développement, de l’optimisation, des débogages, des tests, des mises en production, etc.
augmentation des coûts de production dû à cette augmentation du temps de production, ainsi qu’à à la rémunération des (rares) développeurs stars maitrisant toutes les techs requises
perte d’argent lorsqu’il faut reprendre des applications à cause des changements fréquents des techs, pratiques, et outils tendances

Cette liste pourrait être allongée et détaillée. Mais il faut simplement retenir que d’après les lois d’évolutions de TRIZ, ces problèmes actuels trouveront une solution.

Ne faudrait-il pas juste s’(auto-)former ?

Certains d’entre vous pensent peut-être que la solution, c’est de s’y mettre. D’apprendre les dernières syntaxes, patterns, outils, et frameworks actuels. D’autres diront qu’il faut se spécialiser dans l’un de ces outils et d’y passer le temps qu’il faut. Qu’après tout ça fait partie de notre métier, qu’il faut toujours ce mettre à jour, parce que c’est comme ça.

Mais demander aux développeurs de se former ou de s’auto-former continuellement est sous-optimisé. Justement parce que la formation représente un coût en termes de temps et/ou d’argent.

Et ce coût est non-négligeable, même pour les développeurs confirmés. J’aurai ici voulu pointer sur un article parlant de la javascript fatigue mais il y en a trop et je ne peux choisir. Il y a quelque chose dans cette situation qui ne tourne pas rond…

Ainsi, le coût d’attendre des devs qu’ils se forment continuellement réduit l’idéalité. Ce n’est pas assez efficace. En revanche, il y a une autre solution que j’aimerais proposer.

Simplifions le dev.

Il est intéressant de remarquer que la seule SIMPLIFICATION du développement permet de répondre à chacun des problèmes cités.

En effet, si les nombreux outils concurrents actuels (frameworks, librairies, bundlers, langages, etc.) ont des niveaux de flexibilité et d’efficacité proches, le plus simple deviendra le plus populaire, simplement car il est par définition moins coûteux en efforts, en temps de formation, en temps de développement et donc en coût de production.

Pendant un temps cette règle n’était pas totalement vraie car les entreprises et développeurs orientaient leur choix vers des outils promus par des références comme Google (Angular) ou Facebook (React). En effet, la popularité des créateurs de ces outils rassurait les entreprises, qui y voyaient en fait les bénéfices de la pérennité, de la fiabilité, et de l’optimisation. Leur complexité représentait certes un investissement (en terme de formation notamment), mais un investissement sûr et conférant de nombreux bénéfices.

Or le scandale du passage d’AngularJS à Angular, ou encore la nouvelle popularité des frameworks “challengers” comme VueJS ou Svelte, montre que ce critère de popularité est de moins en moins déterminant dans le choix d’une technologie. Parce qu’on s’est rendus compte qu’on peut faire aussi bien, en (un peu) plus simple.

Ainsi la Simplicité devient petit à petit un critère déterminant car elle augmente l’idéalité : on atteint les même bénéfices pour moins de coûts.

Simplification
= moins de temps de formation et moins d’outils concurrents
= moins de temps de développement et moins de pb dans les choix techs
= moins de coûts de développement, moins de difficultés de recrutement et une meilleure pérennité des applications

Ainsi, il y a tout à parier qu’à performances similaires, les solutions plus simples remplaceront petit à petit les solutions plus compliquées.

Conclusion

Plutôt que de se former continuellement, il nous faut changer de paradigme en simplifiant le développement. Simplifier résout de nombreux problèmes engendrés par les pratiques et habitudes actuelles.

Toutefois, cette simplification ne sera efficace et utile qu’à condition de conserver flexibilité et performance offertes par les outils actuels.

Par où commence t’on pour simplifier le dev ?

Dans Les développeurs n’auront plus à optimiser leurs applications je parle de l’Abstraction, qui constitue un premier moyen pour simplifier le développement.

Mais cette question mérite d’être abordée plus en détails dans mes prochains articles. Celui-ci se voulait introductif : comme le préconise TRIZ, je souhaitais ici préciser l’objectif à atteindre, en gardant en tête l’idéal.

Merci de m’avoir lu jusqu’ici.

Development will become simpler

Alexandre Beaugrand — Sat, 14 Nov 2020 08:38:15 +0000

English version / Version Française ici

As a web developer and trainer for the past 15 years, I have not been spared by the “Javascript Fatigue”. My search for a “cure” to this fatigue, drove me to think about programming absurdities, and what could be the ideal programming environment.

In this introductory article, I would like to talk about my conviction: development will become simpler. Thereafter, I will prepare a series of articles describing in detail the reasons for my opinion. This will hopefully give you a glimpse of what the next development environments, as well as web programming, will look like.

My opinion is inspired by TRIZ

Imagining the future is easier if you use a method. On several occasions, I will refer to TRIZ, a Soviet method that I have been inspired by, which allows us to solve innovation problems as well as to innovate by anticipating the evolution of technologies.

TRIZ has proven its worth: for example, Samsung has been using it for years and it allowed the company to register numerous patents. In addition, this method is taught in schools in South Korea, a country that is highly innovative.

TRIZ includes multiple concepts and tools that I will refer to in my articles. I will mainly refer to the Laws of Technical Systems Evolution, and to the 9 Windows.

Development will tend towards an ideal

The first thing to know, according to the Law of Evolution N°4 — Growth of Ideality, is that programming tools, like any system, will tend towards an ideal. The ideal, in the sense of TRIZ, is defined as follows:

A system is ideal if it offers maximum benefits, without cost, and without harms.

This simple equation therefore challenges a widely held belief among many developers that if today’s tools make it possible to create applications that are more secure, more reliable, more team-oriented, more scalable, and more responsive, they should definitely be used.

These are indeed many benefits brought by modern tools and frameworks. Except that the ideal is not reached for a simple reason:

Current tools and frameworks have a cost and cause some harms

Don’t you think so? Here is a non-exhaustive list:

confusion in the technical choices due to the multiplication of competing tools (frameworks, libraries, and tools/modules of the environments)
lack of apps durabilities, due to these uncertain technical choices, as well as the frequent changes in syntaxes, patterns, and best practices
need to have extensive knowledge and constant (self-)training to master all the best practices required to produce structured, secure, tested and optimized apps
difficulty in recruiting expert and versatile developer profiles, as well as difficulty in finding jobs for developers who are not familiar with the latest tech trends
increase in the overall production time due to the increased needed time for training, environment setup, development, optimization, debugging, testing, building, etc.
increase in the overall production cost due to this increase in the overall production time, and because of the high salaries of the few star developers mastering all of the required techs
loss of money when obsolete apps need to be refactored because of hype techs, hype tools, and good practices frequent shifts

This list could be extended and detailed. But we shoud simply understand that according to the TRIZ laws of evolution, these current problems will find a solution.

Shouldn’t we just learn stuff?

Some of you may think the solution is just to go ahead, and learn the latest syntaxs, patterns, tools, and frameworks. Others may say we should specialize in using one tech, taking the time it takes. Because after all, it’s part of our job. Devs need to keep up to date. Because that’s the way it is.

But asking developers to continually be trained or self-train is under-optimized. Precisely because training represents a cost in terms of time and/or money.

And it is a significant cost, even for experienced developers. Here, I wanted to refer to an article about javascript fatigue but there are too many I can’t choose. Something just doesn’t feel right.

Thus, the cost of expecting devs to continually be trained or self-train reduces ideality. It is not efficient enough. On the other hand, there is another solution that I would like to propose.

Let’s simplify dev.

It is interesting to note that the SIMPLIFICATION of development alone makes it possible to solve each of the problems above mentioned.

If the many current competing tools (frameworks, libraries, bundlers, languages, etc.) offer similar levels of flexibility and efficiency, the simplest will become the most popular, simply because it is by definition less costly in terms of efforts, training time, development time and therefore production cost.

For a while this rule was not totally true because companies and developers were orienting their choice towards tools promoted by references such as Google (Angular) or Facebook (React). Indeed, the popularity of the creators of these tools reassured companies, who saw in them the benefits of durability, reliability, and optimization. Their complexity certainly represented an investment (in terms of training in particular), but a safe investment with many benefits.

However, the AngularJS to Angular switch scandal, and the new popularity of “challengers” frameworks such as VueJS or Svelte, shows that this criterion of popularity tends not the be the most determining factor on tech choice anymore. Because we came to realize that we actually can make things just as well, but in a (little) more simple way.

Thus Simplicity little by little becomes a determining criterion because it increases ideality: allowing us to reach the same benefits, with less costs.

Simplification
= less training time and fewer competing tools
= less development time and less headaches on tech choices
= less development cost, less recruitment difficulties and increased app durability

Thus, there are many reasons to believe that with similar performances, simpler solutions will gradually replace more complicated ones.

Wrapping-up

Rather than continually learning, we should change paradigm by simplifying dev. Simplifiying solves many problems caused by current practices and habits.

However, this simplification will only be effective and useful if we maintain the same flexibility and performance offered by current tools.

Where do we start to simplify dev ?

In Devs won’t need to optimize their apps I talk about Abstraction, which is one way to simplify development.

But this question deserves to be discussed in more detail in my next articles. This one was meant to be introductory: as recommended by TRIZ, I here wanted to specify our goal, keeping in mind the ideal.

Thank you for reading me so far.

Devs won't need to optimize their apps

Alexandre Beaugrand — Sun, 01 Nov 2020 10:45:33 +0000

English version / Version Française ici

Les bénéfices de l’Abstraction

In this article, I'll explain why devs won't need to optimize their apps. It is related to the fact web development will evolve to become simpler, using Abstraction. I'll first compare cars and dev tools evolutions, explain why I think we went the wrong way, and propose a way to solve modern development problems reconsidering devs' roles and source code structure. I'll then talk about a new way to use modern frameworks. I hope you'll get my point.

Let's compare cars and dev tools evolutions

Cars Evolution

Cars have evolved. They became faster, more secure, more efficient, more ecologic. We can say they've been optimized. Yet, has their USE changed ?

No, or not much. A 2020 driver more or less drives like a 1940 driver.

The driver doesn't need to know HOW it is possible to get more speed, more security, more efficiency, or to be more ecologic. Its car deals with it, because a team of specialists worked on these matters and optimized it. There is no need for the driver to understand how it works to gain those benefits.

Dev tools Evolution

Dev tools too have evolved. They craft apps that are faster, more secure, less heavy, more reliable, responsive, etc. We can say they've been optimized as well. Yet has the USE of dev tools and languages changed ?

Drastically. A front-end dev in 2000 just needed to master HTML and CSS. He/she didn't need to operate any framework, to set-up a NodeJS environment, to configure webpack, to understand what are promises, immutables, observables, design patterns, API calls, event delegation, hoisting, or to make TDD.

In 2020, a front-end dev has to master these tools and concepts, otherwise he/she won't develop with the latest trendy techs and will be considered as someone who creates sub-optimized applications.

We went the wrong way

Why is there such a difference between cars evolution vs dev tools evolution ?

Car Users

For what concerns cars, the user of the car is clearly identified (Mr. Everyone) and separated from the makers of the car (engineers, mechanics, designers, etc.).

It is not conceivable to expect the user to know how its car works in order to operate it and to take advantage of its latests features and optimizations.

Dev Tools Users

For what concerns dev tools, both the users and the makers of those tools are developers.
Thus, it naturally feels much more conceivable to expect the users of these tools to understand dev tools magic, and to adopt the best coding practices that produce teamwork, maintainability, and optimization.

This is why currently, mastering a framework for example requires a long learning process: its implementation and its boilerplate must be demystified, the major CLI commands must be known, its organization and its design patterns must be clarified. It is also necessary to understand what are the main classes / functions used, and what key concepts it is necessary to adopt (the state must be immutable, the functions must be pure, etc.).

What's wrong with modern dev

Asking dev tools users to understand ever-evolving concepts is just like expecting a car user to understand what kind of rubber its tire are made of to be safer, what frequencies its parking radars use, or how fuel injection works.

This should stay under the hood, even if the car user turns out to be an engineer and would be able to understand. Because taking the time needed to understand this incurs a cost in terms of efforts, training time, practice time, debugging time, and therefore in development cost.

Thus, it is underoptimized to expect the users of dev tools to acquire all this knowledge in order to benefit of better teamwork, maintainability and optimization.

Like the car makers, mastering those concepts should remain the job of a particular type of developer who specializes in making dev tools.

2 new types of devs

Instead of a distinction between front-end devs and back-end devs (which makes less sense anymore), I suggest you imagine a disctinction between dev. tools users and dev. tool designers.

Dev tools users

The dev. tools users are in charge of making the best websites and apps according to the specs/client needs. They know how to create relevant UI, describe their components, their features, and the interactions involved.

Dev tools designers

The dev. tool designers are specialists mastering the most optimized code structures, and the most relevant design patterns to solve a given problem. They are in charge of creating and upgrading dev tools to perform the same functions (event detection, interface modification, backup, authentication, etc.), but in an ever more efficient manner.

App vs Engine

It is possible to build apps that facilitate teamwork, are optimized and maintainable, without the requirement of mastering ever-increasing programming concepts and best practices. We can achieve this by separating app vs engine.

App

Dev. tool users should only take care of describing their apps (features, interactions, components, UI).

One way would be to describe apps visually. NoCode apps such as bubble.io propose to do so, and then translate each app visual description into a real app. Many devs think these are limited, but I suggest you try their 5min tutorials to see how much flexibility you can get.

Another way of doing this would be to use a single highly abstracted language that looks like writing specs, but in a much more programmatic (thus structured) way. For example:

There is the possibility of identifying the user 
via [email / pass / fingerprint / eye / etc.] 
materialized by [a login box with 2 fields / a device / etc.].
This box will use [db records / file records / etc.]. 
If successful, we will 
[access a page / add a database log / send an e-mail / etc.].

This language would be written in a single development tool, which would be configured to use an optimization engine among others. For the functionality of identifiying the user, each engine would offer many options for what concerns, for example, inputs [email / pass / borrows / retina / etc.], display [a login box of 2 fields / a device / etc.], relations [records in database / records in file / etc.], or output actions [access a page / add a log in database / send an e-mail / etc.].

Engine

Dev. Tool designers would actually work on the engines. They would be in charge of translating app descriptions into optimized, well structured, well tested, bug-free code. Once on a while there would be an update of an engine, for ever-better performances. Each update would not break anything because engines would be totally independant from app descriptions.

To get an idea of how it would work, you may think about what happened with PHP, since its core has been refactored many times. PHP7 is for example way faster than its predecessors, but as a PHP dev you don't need to understand or care about what have changed internally. The new version allows for better perfs, even if you stick to the same app code. That's all you need to know.

You may also think about relational databases, where the app / engine separation already exists as well. MyISAM, or InnoDB engines offer differences while being linked to the same SQL language.

Frameworks could become engines

Most framework are a result of quality work, given the numerous specialists involved in making them. Therefore, not using those tools would be a waste, and yet I believe relying on dev tool users to master so many concepts in order to operate those frameworks is underoptimized.

When you first read about a new framework on its official website, you soon come accross the Why this framework section. Most frameworks emphasize their low weight, reactivity, etc. While these features are certainly relevant for app engines, frameworks lack ease of use (even if some claim to be simple) because they are too low-level, which I believe don't make them good candidates as app description tools.

Since we should separate app description tools from engines, we can imagine app description code could scaffold apps in different flavors (or frameworks). The same source code could create a React, Angular, Ember, or Vue app. Or it could generate a Laravel or Ruby app. All frameworks would become interchangeable engines as their code would be generated based on the dev choice.

This concept is close to hybrid phone apps. For example, PhoneGap or Ionic are capable, with almost the same base code, to generate Android or iOs apps.

Wrapping up

TRIZ laws of Evolution explain that every systems tends to an ideal, which means less costs. Pattern number five also states that systems increase in complexity and then get simplified.

App developement has already increased in complexity. Now it is time to simplify. What I suggest in this article is a response to this need of simplicity.

If developer roles get to be redefined, if apps get separated from their engines, and if we use a highly abstracted language describing apps, we obtain more efficiency.

And for every new tool / framework update, there would be no more learning costs. Just a pop-up in the dev tool.

With a button : [update engine].