Le développement va se simplifier

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.