Une loi systémique veut que "toute frontière est arbitraire". On entend par là que toute ligne que vous tracez pour ranger des éléments en deux catégories, se révèle tôt ou tard inadéquate.
Par exemple : un logiciel est écrit par des développeurs, et employé par des utilisateurs.
Les premiers écrivent le code, les seconds s'intéressent à l'exécution.
Il s'agirait de deux moments bien distincts.
J'ai bien souvent pu mesurer à quel point c'était faux.
Quelques exemples où le comportement du logiciel évolue à l'exécution, parce que les utilisateurs écrivent du "code" :
- Un formule Excel fournit des résultats calculés
- Un formulaire affiche dynamiquement certaines questions en fonction des réponses précédentes
- Un moteur de scoring dépend de règles définies par le business
- Un e-commerce calcule des remises en fonction du groupe d'utilisateur et de la saison
- Un import de données permet à ses utilisateurs de passer certaines lignes, sous condition
- etc.
J'ai trop longtemps vu un développeur (parfois moi-même) créer des interfaces utilisateurs aussi complexes que limitées pour que ses utilisateurs puissent exprimer leurs conditions avec une vague autonomie. Ou inventer des langages d'expression ad-hoc tout pourris, aussi simplistes que limités.
Pour deux raisons. D'une part une difficuté technique réelle d'embarquer un compilateur dans un logiciel (Excel est né en 85). D'autre part, une forme de condescendance de l'industrie : les utilisateurs finaux sont évidemment trop cons pour savoir écrire du code.
Donnons-leur donc des langages et interfaces utilisateurs pourries et limitons-les dans ce qu'ils peuvent calculer eux-mĂŞmes.
Bref, il était temps que cela change.
Elo n'a pas d'autre vocation que celle là : permettre plus facilement au code d'être écrit at runtime, et permettre que ce code soit écrit par des non-développeurs, certainement aidés par l'IA.
#Elo #SoftwareEngineering