Malgré les avantages de la simplicité, la complexité se vend malheureusement mieux (2022)
(eugeneyan.com)- Derrière le fait que les approches simples soient moins bien évaluées lors de l’examen d’articles ou des évaluations de promotion se trouve un biais de complexité : les productions complexes semblent contenir davantage d’efforts, de maîtrise et d’innovation.
- Les systèmes comportant beaucoup d’options et de composants peuvent paraître flexibles, mais en exploitation réelle, ils deviennent plus difficiles à expliquer, tester et dépanner, ce qui peut accroître les erreurs et l’inefficacité.
- Les idées et systèmes simples sont faciles à comprendre, utiliser, améliorer par feedback et étendre. Lors de son acquisition en 2012, Instagram servait des dizaines de millions d’utilisateurs avec une équipe de 13 personnes, tout en conservant des technologies éprouvées comme PostgreSQL et Redis.
- En machine learning aussi, les techniques complexes ne sont pas toujours supérieures : sur 45 jeux de données tabulaires de taille moyenne, les modèles à base d’arbres ont surpassé les réseaux de neurones profonds, et dans la recommandation et la recherche, le produit scalaire (dot product) a fait mieux que le neural collaborative filtering.
- Récompenser la complexité en tant que telle encourage la complexification inutile et la tendance not invented here ; face à un problème complexe, il faut donc d’abord se demander si une solution simple est possible et si le coût de la complexité est justifié.
Pourquoi la complexité paraît plus séduisante
- La complexité est facilement perçue comme un signal d’effort
- Un article rempli d’idées difficiles et de détails techniques donne l’impression d’avoir demandé beaucoup de temps et d’efforts.
- Un système comportant de nombreux composants et fonctionnalités est plus facilement jugé comme un résultat plus travaillé qu’un système plus petit.
- L’impression qu’une chose est difficile à construire fonctionne alors comme un signal de valeur et de qualité.
- Elle est aussi interprétée comme un signal de maîtrise
- Un système avec beaucoup de pièces mobiles donne l’impression que ses concepteurs ont la capacité de comprendre et d’intégrer chaque partie.
- Un article riche en jargon et en démonstrations est difficile d’accès, mais semble d’autant plus montrer une expertise du sujet.
- La pratique consistant à poser en entretien des questions sur des algorithmes et structures de données rarement utilisés en pratique est également liée à ce signal.
- Elle est aussi perçue comme un signal d’innovation
- Un article qui crée une architecture de modèle entièrement nouvelle est plus facilement jugé plus novateur qu’un article qui modifie un réseau existant.
- Un système comportant beaucoup de composants créés from scratch paraît plus original qu’un système qui réutilise des briques existantes.
- Le jugement « on ne change qu’une chose, le reste est identique aux travaux existants » peut diminuer la valeur perçue d’une idée simple.
- Plus il y a de fonctionnalités, plus naît l’illusion d’une couverture globale
- Un système qui prend en charge à la fois des stockages de données SQL et NoSQL, ou qui permet à la fois des pipelines batch et streaming, semble couvrir tous les cas.
- Plus il y a de briques Lego, plus on pense pouvoir mieux s’adapter au changement.
- Ce type de jugement conduit à un complexity bias, une préférence excessive pour le complexe par rapport aux idées et systèmes simples.
Là où la simplicité devient un véritable avantage
- Les idées et fonctionnalités simples sont faciles à comprendre et à utiliser
- Elles augmentent les chances d’adoption et l’impact réel.
- Elles sont aussi plus faciles à transmettre et à améliorer grâce au feedback.
- Les systèmes complexes sont difficiles à expliquer et à gérer, ce qui complique pour les utilisateurs la compréhension de ce qu’ils doivent faire et comment.
- Quand il y a trop d’éléments à ajuster, les erreurs augmentent ; quand il y a trop d’étapes, l’inefficacité apparaît.
- Les systèmes simples sont plus faciles à construire et à faire évoluer
- Moins il y a de composants, plus l’implémentation devient facile.
- En utilisant des technologies standardisées et éprouvées, il est plus facile de trouver des personnes capables de les implémenter et de les maintenir.
- La réduction du code et des interactions internes diminue aussi la charge de compréhension et de test.
- Les systèmes inutilement complexes consomment davantage de temps et de ressources à construire, ce qui crée du gaspillage.
- Le cas Instagram illustre les avantages de choix technologiques simples
- Lors de son acquisition en 2012, Instagram servait des dizaines de millions d’utilisateurs avec une équipe de 13 personnes.
- En conservant des technologies éprouvées plutôt que de nouvelles technologies à la mode, l’entreprise réduisait la charge opérationnelle par ingénieur.
- Alors que d’autres startups adoptaient des stockages de données NoSQL à la mode et rencontraient des difficultés, Instagram utilisait PostgreSQL et Redis, faciles à comprendre.
Coûts d’exploitation et maintenabilité
- Le déploiement d’un système n’est pas la fin, mais le point de départ
- La majeure partie des efforts survient après la mise en production.
- L’exploitation a de fortes chances d’être assurée par d’autres personnes que l’équipe qui l’a créé au départ.
- Un système simple peut réduire les coûts de maintenance et prolonger sa durée de vie.
- Moins il y a de pièces mobiles, plus le système est fiable et facile à réparer
- Le nombre de parties susceptibles de tomber en panne diminue.
- Avec moins d’interactions internes, il est plus facile de mettre à niveau ou de remplacer des composants individuels.
- Dans un système complexe, une équipe limitée doit comprendre davantage de composants, ce qui augmente les coûts de maintenance.
- Plus les parties sont interdépendantes, plus le dépannage devient difficile.
- Thomas Paine écrit dans 『Common Sense』 que « plus une chose est simple, moins elle risque de se dérégler, et plus elle est facile à réparer lorsqu’elle se dérègle ».
En machine learning aussi, les techniques simples ne sont pas dépassées
- Les techniques plus sophistiquées ne donnent pas toujours de meilleures performances
- Tree-based models > deep neural networks : sur 45 jeux de données tabulaires de taille moyenne, les modèles à base d’arbres surpassent les réseaux de neurones profonds.
- Greedy algorithms > graph neural networks : pour des problèmes combinatoires sur graphes, les algorithmes greedy surpassent les graph neural networks.
- Simple averaging ≥ complex optimizers : dans les problèmes d’apprentissage multitâche, une simple moyenne fait au moins aussi bien que des optimiseurs complexes.
- Simple methods > complex methods : sur l’ensemble de 32 articles, les méthodes simples dépassent les méthodes complexes en précision de prédiction.
- Dot product > neural collaborative filtering : dans la recommandation et la recherche d’items, le produit scalaire dépasse le neural collaborative filtering.
Les problèmes créés quand on récompense la complexité
- Récompenser la complexité incite les gens à construire des choses inutilement complexes
- Une méthode ou un système simple peut être jugé moins précieux simplement parce qu’il paraît facile.
- Si l’on complexifie un système pour obtenir une récompense, la solution la plus simple n’apparaît plus comme un choix évident.
- La complexité engendre davantage de complexité, jusqu’à pouvoir rendre le travail impossible.
- La tendance not invented here se renforce également
- Même lorsque réutiliser des composants existants permettrait d’économiser du temps et des efforts, une tendance à tout construire à partir de zéro apparaît.
- Cela peut gaspiller du temps et des ressources, et mener à de moins bons résultats.
- Dans les procédures de promotion et l’évaluation d’articles de machine learning, la complexité peut aussi être excessivement mise en avant
- Bryan Liles souligne que les solutions simples sont plus faciles à implémenter et à faire évoluer que les solutions complexes, mais que les promotions sont souvent accordées aux personnes qui ont construit des solutions complexes.
- Micah Goldblum explique que, dans les reviews ML, il est courant de reprocher à une méthode d’être trop simple ou composée de briques existantes, alors que la simplicité n’est pas une faiblesse mais une force.
- Des innovations comme les Kalman Filters, PageRank, SVM, LSTM, Word2Vec ou Dropout ont elles aussi déjà été rejetées.
Une meilleure manière de traiter la complexité
- L’objectif est de résoudre des problèmes complexes avec des solutions aussi simples que possible
- Il faut se concentrer sur la complexité du problème, et non sur celle de la solution.
- Une solution simple montre une compréhension profonde du problème et la capacité à éviter des solutions plus tortueuses et coûteuses.
- Cela rejoint la phrase d’Albert Einstein : « Tout doit être rendu aussi simple que possible, mais pas plus simple. »
- On peut envisager plusieurs solutions ciblées plutôt qu’une solution complexe qui couvre tout
- Une solution universelle (one-size-fits-all) peut se révéler moins flexible et moins réutilisable qu’espéré.
- Prendre en charge simultanément plusieurs cas d’usage et parties prenantes crée un couplage fort, et nécessite davantage de coordination pour la planification et les migrations.
- Un système à objectif unique est plus facile à exploiter, et aussi plus facile à abandonner lorsque c’est nécessaire.
- Pour réduire le biais de complexité, on peut appliquer Occam’s razor
- Le principe veut que la solution ou l’explication la plus simple soit généralement la bonne.
- Il ne faut pas rejeter trop vite une idée simple, ni ajouter une complexité inutile pour justifier sa valeur.
- Il faut tenir compte du coût de la complexité et demander : « est-ce que cela en vaut la peine ? »
Le biais inverse : réutiliser une complexité familière
- À l’opposé du « not invented here », il existe aussi un biais qui favorise automatiquement les composants existants
- Parce qu’on les connaît déjà, ils sont plus faciles d’après l’expérience personnelle et réduisent son propre temps et ses propres efforts.
- Mais si le composant existant est lui-même très complexe, il peut faire perdre plus de temps et de ressources, et produire de moins bons résultats que de construire quelque chose de plus simple.
- Quand aucune option simple n’existe, il peut être nécessaire de construire du neuf
- Il arrive aussi que ce qui est construit à neuf ne devienne pas réellement plus simple, mais seulement un autre objet aussi complexe que l’existant.
- Certains problèmes sont intrinsèquement complexes et possèdent une essential complexity qu’on ne peut pas réellement supprimer.
- Les ORM sont présentés comme un mauvais exemple
- Les ORM sont constamment recréés et commencent simplement, mais leur complexité finit par exploser.
- L’object/relational impedance mismatch est bien connu, et l’idée même d’ORM est intrinsèquement complexe.
- Ce qui semble avoir conservé sa simplicité a probablement plus de chances d’être un query builder ou un data mapper qu’un ORM.
- L’API de cache PSR est un exemple de complexité supprimable
- Après l’API de cache PSR-6, une API de cache plus simple, PSR-16, est apparue.
- PSR-16 réduit la complexité et le nombre de concepts, rendant l’API plus petite et moins prescriptive.
- Le fait qu’il soit possible de créer un adaptateur PSR-6 pour implémenter PSR-16 et un adaptateur dans l’autre sens montre que la complexité supprimée dans PSR-16 n’était pas essentielle.
- Certaines bibliothèques et frameworks peuvent grossir au-delà de la complexité essentielle au nom de l’expérience développeur
- La véritable simplicité possède des aspects mesurables, comme le nombre de lignes de code, le nombre de méthodes publiques ou le couplage.
- Certaines bibliothèques deviennent 10 fois plus grosses que leur taille initiale en quelques années et publient de gros breaking changes tous les 6 à 12 mois.
- Considérer une bibliothèque qui ne grossit pas comme « morte » et vouloir migrer vers un package plus « actif » peut aussi être un symptôme du biais de complexité.
- Pour éviter la propagation de la complexité, il peut parfois être nécessaire de construire du neuf
- Si les exigences peuvent être figées et si l’on peut éviter une croissance incontrôlée du périmètre, une nouvelle implémentation peut être le choix le plus simple.
- Il faut veiller à ne renforcer aucun des deux biais.
1 commentaires
Commentaires sur Hacker News
J’ai travaillé à une époque dans une entreprise de la FAANG où résoudre des problèmes complexes servait de critère de promotion, et plus on résolvait de problèmes complexes, plus on montait en niveau, en rémunération et en statut
Naturellement, les gens se sont mis à chercher des problèmes complexes à résoudre, et à mesure que d’autres entreprises copiaient les idées de cette société, même de petites entreprises qui n’avaient pas besoin de solutions complexes ont fini par adopter des stacks techniques similaires
En voyant les UI complexes et pénibles à utiliser des voitures actuelles, surtout des véhicules électriques, j’ai eu une réflexion similaire, au point que ça me dissuade d’acheter une voiture qui en a besoin
La conclusion, c’est que les consommateurs sophistiqués et les consommateurs aspirationnels sont très différents, et que les seconds sont bien plus nombreux
Donc sacrifier les consommateurs sophistiqués pour s’aligner sur les consommateurs aspirationnels est économiquement rationnel
Les consommateurs aspirationnels tolèrent les défauts et les artifices, car ils les acceptent comme des symboles de réussite à la consommation
En caricaturant, ils aiment tellement conduire une voiture « de luxe » qu’ils ne voient pas les déchets livrés avec, alors que de mon point de vue de quelqu’un qui achète des voitures de luxe depuis des décennies, j’aimerais simplement qu’un levier de vitesse soit facile à identifier
Les cibles tactiles sont devenues beaucoup trop petites sans raison, et on dirait que les développeurs ont conçu et testé l’UI sur un écran posé sur un bureau fixe ou dans une voiture à l’arrêt
Dans une voiture en mouvement, tout s’effondre
Les voitures récentes sans levier de vitesse, sans clignotants, sans essuie-glaces ni commodo d’éclairage sont un chaos total
Devoir s’asseoir au volant et essayer de toucher de petites cibles sur un écran où l’on n’a même nulle part où poser la main aggrave la conduite à cause de l’interaction indirecte, de la confusion, du manque de précision et de la distraction
Ça automatise les corvées comme verrouiller/déverrouiller, fermer les vitres, préchauffer/prérefroidir, régler automatiquement la navigation vers le bureau le matin et vers la maison le soir, ou ajuster le siège et les réglages selon la clé téléphone utilisée
Grâce à la connectivité gratuite, la navigation fonctionne correctement, alors que tous les GPS embarqués que j’ai utilisés auparavant étaient inutiles
L’écran de sélection et de lecture de la musique est bien fait, et les commandes vocales marchent plutôt bien pour choisir la musique
Ce n’est pas parfait, mais à mon avis c’est mieux que toutes les voitures thermiques que j’ai conduites jusqu’ici
Le matin, partir au bureau se résume à deux étapes : ouvrir la porte et passer en mode conduite
En hiver, avec une voiture thermique, c’était plus de dix étapes : trouver la clé, déverrouiller la voiture, ouvrir la porte, régler le siège après que ma femme a conduit, appuyer sur le bouton de démarrage, dégivrer le pare-brise, activer le dégivrage de la lunette arrière, gratter la glace sur le pare-brise, sélectionner le bureau dans le GPS, desserrer le frein de parking, embrayer et passer une vitesse
Des gens qui n’en ont jamais possédé se lamentent sans cesse en ligne sur l’écran tactile, mais les propriétaires de Tesla restent chez cette marque parce qu’elle est supérieure aux autres voitures, écran tactile ou pas
Dans une vidéo récente, Technology Connections racontait qu’il avait dû maintenir pendant 4 secondes un levier affreux style années 90 pour changer les essuie-glaces, et qu’il avait dû lire le manuel pour comprendre ça
Ce genre de comportement nul est très courant dans les voitures faites de pièces assemblées séparément
À l’inverse, ma voiture m’envoie sur mon téléphone des alertes vidéo de surveillance en temps réel, gère ma conduite du trajet domicile-travail, et pour le changement de vitesse, en général il suffit de mettre sa ceinture et d’appuyer sur le frein pour qu’elle choisisse elle-même la direction
Les fonctions importantes sont accessibles contextuellement via le volant, pas via 50 boutons
C’est simple et puissant, et le problème, c’est surtout que l’exécution des voitures de luxe mentionnées plus haut est médiocre
Je regarde parfois le YouTuber Theo Browne, qui est principalement développeur front-end.
Quand je le vois expliquer des solutions, j’ai l’impression de recevoir un coup de batte de baseball sur la tête, et le nombre d’éléments dans ses démos est à en pleurer.
Je suis aussi frappé par le nombre de termes obscurs liés à React qu’il mentionne dans une seule vidéo.
Je ne cherche pas à attaquer quelqu’un en particulier, mais je me demande si ce n’est pas justement cette complexité qui entretient sa popularité.
À l’inverse, Pieter Levels pousse directement du PHP brut en production sans parler de Suspense, de rendu côté serveur ou d’Hydration.
Au final, ils arrivent tous les deux au même objectif, mais Pieter Levels gagnera probablement bien plus d’argent, et l’écart de complexité est énorme.
En fait, quelque chose comme Nomad List me semble aussi beaucoup plus riche en fonctionnalités que ce que je vois chez Theo.
Ensuite, quelqu’un d’autre l’a reconnu, et j’ai vu Theo se lancer dans un débat amical mais bruyant sur un sujet qu’il défendait fortement sur sa chaîne.
Sa personnalité semblait parfaitement adaptée à maximiser l’attention médiatique via une complexité inutile.
Plus c’est complexe, plus il y a matière à controverse, et plus on peut paraître intelligent aux yeux de ceux qui ne sont pas habitués à ces choix ésotériques.
La quantité de bibliothèques et de code utilisée dans ces exemples-jouets est bien plus grande que ce que je vois en production, et j’ai pourtant déjà vu des systèmes assez monstrueux.
Je ne sais pas combien de temps ça peut durer.
On embarque plein de choses accessoires qu’on n’utilisera jamais, et qui gênent au passage les parties qu’on veut vraiment utiliser.
Quand un problème survient, il faut alors comprendre non seulement le langage de programmation et son propre code, mais aussi le code du chemin qu’on traverse à l’intérieur du framework.
Ce chemin peut facilement descendre à 10 ou 20 fonctions de profondeur, et il est extrêmement rare que la documentation décrive avec assez de précision ce qui se passe dans les différents cas limites.
La quantité d’outils utilisée pour fabriquer quelque chose de relativement simple est énorme, et j’ai l’impression qu’on voit la même chose en DevOps.
J’ai l’impression que ce problème a été créé par les « développeurs front-end » des entreprises.
Une sorte de complexe d’infériorité vis-à-vis de la « vraie ingénierie » faite par les développeurs full-stack ou back-end a peut-être poussé le front-end à vouloir lui aussi se créer des problèmes de « vraie ingénierie ».
Après des décennies passées à développer des systèmes legacy, dans notre entreprise comme pour des missions chez des clients, j’ai souvent vu qu’on amenait certains clients à préférer des logiciels complexes et pleins de bugs.
La raison, c’est que cela leur permet de s’y cacher.
« Le logiciel avait un bug, donc je n’ai pas pu finir à temps », « le logiciel ne prenait pas en charge Y, donc je n’ai pas pu faire X », « le chien a mangé mon devoir », ce genre de choses.
Dans bien des cas, on aurait pu concevoir une solution simple, facile et avec bien moins de bugs, mais alors les utilisateurs auraient eu beaucoup plus de mal à cacher le fait que certains échecs venaient peut-être non du logiciel, mais de leur propre incompétence.
C’est pourquoi, surtout dans les entreprises où la pression venue d’en haut est forte, les managers préfèrent en réalité travailler avec des logiciels qu’ils ne comprennent pas complètement et qui sont connus pour avoir des bugs et des problèmes.
À 27 ans, quand j’ai quitté mon premier emploi après cinq ans, j’ai remplacé un programme GUI ultra-complexe par une petite interface graphique qui enveloppait deux programmes CLI.
Ça fonctionnait à tous les coups, même avec des entrées erronées, et dans les rares cas où ça échouait, ça renvoyait des messages d’erreur utiles.
Les trois femmes qui l’utilisaient me détestaient vraiment.
Ce n’est qu’environ un an après avoir quitté l’entreprise que j’ai compris pourquoi, et à l’époque je n’étais pas très malin.
Avec le temps, j’en suis venu à penser que les gens veulent des choses comme Microsoft Teams parce que ça leur permet de se couvrir quand ils en ont besoin.
Pour les interfaces physiques, dans notre groupe on appelle ça le problème du micro-ondes.
Personne n’utilise les 20 boutons supplémentaires d’un micro-ondes et la plupart des gens n’en utilisent qu’un ou deux, mais personne n’achète un micro-ondes avec peu de boutons.
J’adore mon Samsung ME82V depuis 10 ans, et deux molettes me suffisent.
Donc grignoter en douce à 2 heures du matin revient à surveiller le micro-ondes comme en 1999.
Tout ce que je veux, c’est une molette de vitesse, un bouton d’impulsion et un bouton d’alimentation, et tout le monde veut ça, mais pour une raison quelconque, à chaque génération on y ajoute une foule de fonctions que personne n’utilise.
Je n’utilise pas forcément toujours les mêmes deux boutons, donc j’aime avoir la possibilité d’utiliser les autres.
Et assez souvent, davantage de boutons s’accompagnent aussi de meilleures spécifications.
Il y avait moins de commandes et moins de fonctions, mais l’expérience utilisateur était excellente.
Je me souviens de la sobriété de l’iPod comparée aux produits concurrents surchargés de fonctions et de complexité.
Ce genre de lamentation est agaçant parce qu’il est rempli de lieux communs.
Il est facile de paraître intelligent en citant Einstein et Dijkstra, et tout aussi facile de généraliser des solutions complexes et de les montrer du doigt avec le recul et l’ignorance des exigences réelles.
« Aussi simple que possible, mais pas plus simple » est toujours vrai.
Si une solution est bancale, c’est qu’elle aurait dû être rendue plus simple ; si une solution primitive pose problème, c’est qu’elle n’aurait pas dû être rendue trop simple.
C’est du niveau de « pourquoi n’avez-vous pas simplement pensé à la rendre parfaite ? »
Dans la réalité, quand une solution implique plusieurs compromis, il est déjà très difficile de se mettre d’accord sur ce qui est simple.
Il peut être plus facile de maintenir une base de données complexe que de gérer trois bases de données « simples », tripler le travail d’administration, puis finir par implémenter de la synchronisation ou des transactions distribuées.
Ce qui est facile à implémenter aujourd’hui peut créer des problèmes complexes plus tard, et une solution existante qui ne résout pas complètement le problème peut engendrer des contournements complexes pour les cas non pris en charge, auxquels s’ajoute ensuite la complexité de migrer vers quelque chose d’approprié.
Le conseil « faites simplement simple » part souvent du principe qu’une telle solution est universelle, sans voir qu’en réalité il existe rarement un choix clair entre complexité et simplicité.
Les projets ont des contraintes : systèmes existants bricolés, exigences légales incohérentes, besoins métier changeants ; on peut aussi privilégier la vitesse de livraison ou les compétences qu’on peut réellement recruter.
L’économie est impitoyable aussi : même si la génération du rapport annuel ressemble à une machine de Rube Goldberg, elle ne sert qu’une fois par an, et sa réécriture peut ne pas être rentabilisée avant 50 ans.
Les discussions sur la complexité reconnaissent rarement que les projets et les exigences grandissent.
Ce qui est parfaitement simple aujourd’hui peut devenir complexe plus tard d’une manière totalement rationnelle, et non par incompétence ou malveillance.
Au départ, stocker les données dans un simple fichier texte est d’une belle simplicité, mais plus tard cela peut devenir une pitoyable base de données NIH.
Cela dit, utiliser une base de données dès le départ pour trois lignes de données, c’est aussi du sur-engineering.
Le refactoring a un coût, donc utiliser en permanence la solution idéale n’est pas si simple non plus.
Bien moins de choses qu’on ne le pense sont réellement évidentes.
Interpréter « aussi simple que possible, mais pas plus simple » comme une exigence de perfection ne découle pas logiquement de la formule.
Dans la pratique, on sait que l’itération bat le plan.
S’il est difficile d’obtenir un accord sur ce qui est simple, mieux vaut demander pardon que permission.
C’est une règle qui vaut dans ce secteur, et sans doute dans beaucoup d’autres.
Il existe clairement un certain type de complexité accidentelle qu’on retrouve chez les rêveurs et les développeurs front-end.
La complexité, c’est compliqué.
Les systèmes plus complexes ont aussi un effet secondaire : ils génèrent beaucoup de matériel annexe, comme des tutoriels ou des vidéos.
En outre, pour ceux qui les ont appris, cela leur donne dans l’entreprise des compétences et des responsabilités recherchées, donc plus de sécurité de l’emploi qu’une solution qui fonctionne simplement et ne nécessite personne pour s’en occuper.
Il y a beaucoup trop d’emplois en IT qui n’existeraient pas si les logiciels étaient conçus de façon simple et qu’ils fonctionnaient tout simplement.
Dans les cas simples, « ça marche tout seul », mais seulement tant qu’on ne cherche pas à regarder à l’intérieur ou à faire quelque chose de non trivial.
La comparaison est peut-être assez juste.
Si l’on parle d’évaluation d’articles scientifiques, en tant que relecteur, ce que je cherche dans un article n’est ni la simplicité ni la complexité, ni même la « nouveauté ».
Ce que je cherche, c’est une analyse empirique approfondie et stimulante du problème.
Parmi les soumissions, il y en a beaucoup qui 1) proposent un système façon Frankenstein cousu à partir d’une dizaine d’idées existantes, réussissent à obtenir de « gros chiffres » en mobilisant au maximum les derniers gadgets à la mode, sans analyser en profondeur les modes d’échec de chaque composant ; ou 2) modifient légèrement une méthode existante, obtiennent par hasard de meilleures performances, mais sans fournir de justification empirique ou théorique correcte expliquant pourquoi cela aide.
Le second type peut avoir un peu de valeur pour la communauté ou les lecteurs, mais à mes yeux c’est généralement inutile.
Ce qui a de la valeur pour le lecteur, c’est le cas où un doctorant a longuement étudié un problème, puis relié son intuition à une confirmation quantitative et vérifiable, pour aboutir à des observations reproductibles ayant un pouvoir prédictif.
Par exemple : « nous avons validé expérimentalement dans tous les cas que X influence Y via le mécanisme Z décrit dans cet article ; cela a amélioré la métrique A de B %, ce qui est cohérent avec Z ».
Indépendamment de la complexité, dire simplement « nous avons fait X et A a augmenté de B % » ne suffit pas.
Malheureusement, tous les relecteurs ne sont pas d’accord.
Mon professeur d’histoire au lycée avait donné comme devoir une dissertation sur les événements ayant conduit à la Seconde Guerre mondiale.
La première question fut : quelle longueur doit-elle faire ? Le professeur répondit que si quelqu’un parvenait à traiter ce sujet complexe en une page A4, il lui mettrait la note maximale, mais qu’il doutait sincèrement qu’on puisse le faire dans un texte aussi court.
Tout le monde fut choqué par ce raisonnement.
Personne ne l’avait jamais entendu dire quelque chose comme ça, ce qui montre bien qu’on nous apprend dès l’enfance que plus, c’est toujours mieux.
Une explication peut toujours être rendue longue ou courte selon le niveau d’abstraction choisi, et les gens choisissent généralement ce niveau selon le contexte et les conventions sociales.
Par exemple, « comment une frappe au clavier devient-elle un caractère à l’écran ? » peut s’expliquer en une phrase, ou remplir plusieurs gros livres si l’on inclut le firmware, la pile logicielle, l’électronique, la science des matériaux et les procédés de fabrication.
On peut aussi dire que la Seconde Guerre mondiale a commencé quand Hitler a envahi la Pologne et la France, ou remonter au traité de Versailles, voire à l’évolution de la vie sur Terre.
La dernière option est pédante, mais techniquement, cela fait bien partie des événements ayant conduit à la Seconde Guerre mondiale.
Recommande vivement la conférence Simple Made Easy de Rich Hickey
La complexité ne se vend pas du tout bien, mais ce qui est facile, oui
Si une entreprise peut recruter beaucoup de personnes qui savent utiliser « foo » et que le secteur continue de parler de « foo », alors elle le choisira même si foo est un bazar complet
Il suffit de regarder l’architecture lambda, la plupart des projets Apache, les conteneurs, etc.