The curious relationship between simplicity and top-performance

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 is not 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.

Usain Bolt’s smile

La curieux lien entre Simplicité et Performance

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.

Le sourrire d'Usain Bolt

Le développement va se simplifier

Le développement va se simplifier

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.

[Genrikh Saulovich Altshuller](https://matriz.org/about-matriz/about-founder/), inventeur de TRIZ

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 :

Source : [TRIZ for Engineers: Enabling Inventive Problem Solving](https://www.triz.co.uk/structured-innovation), par Karen Gaad

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.

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

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

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 point de vue vous paraitra pertinent.

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](https://bubble.io/welcome)

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 ](https://phonegap.com/)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].