index.md 21KB
title: Simplicité par défaut slug: simplicite-defaut date: 2016-04-22 chapo: Une forme de décroissance technique pour revenir aux fondamentaux.
Ce billet est un accompagnement à l’intervention donnée lors de Mix-IT. Je n’appelle plus cela des résumés car ce n’est pas forcément ce qui est exprimé le jour J, il s’agit davantage d’un complément.
Il s’agit de la suite de mes recherches relatives au minimalisme et à l’esthétique. J’ai choisi de faire une suite pour des raisons assez personnelles, une sorte d’introspection thérapeutique. La préparation de la précédente intervention m’avait mis dans un état assez douloureux d’incohérence entre mon quotidien et ce que je prônais. J’avais besoin d’aller plus loin pour identifier les raisons profondes qui me poussaient à la recherche de cette simplicité.
Paternité
- Ajouter des couches
- Changer des couches
- Enlever des couches
- Changer des couches
- Mettre des couches
J’en suis à l’étape 3 dans ma maturité en tant que développeur. La paternité change les priorités et je pense qu’elle a un grand rôle dans le fait de vouloir remettre le focus sur la valeur apportée plus que sur la technique. Me battre pour une meilleure expérience utilisateur plutôt que contre un framework, chercher à se faire plaisir davantage via ce qui est produit que par un contentement technique.
Je suis un expérimentateur en ce sens que j’écris pour me changer moi-même et ne plus penser la même chose qu’auparavant.
Michel Foucault
Lorsque j’expérimente aujourd’hui, ce n’est plus pour découvrir une nouvelle bibliothèque mais pour trouver de nouveaux moyens de simplifier un problème. Dans ce contexte, il est intéressant de re-questionner la page blanche (cache), de re-challenger certaines bonnes pratiques communément admises (cache).
Enseignement
Le fait de donner des cours m’a permis de réaliser à quel point nos outils sont complexes et élitistes. L’expression japonaise 「灯台下暗し」 (tōdai moto kurashi) prendre du recul pour avoir de la lumière (littéralement : il fait sombre sous la lanterne) me semble appropriée, ce sont les étudiants qui sont arrivés avec leurs lanternes et ont commencé à me faire sérieusement douter. Je leurs suis extrêmement reconnaissant de m’avoir ouvert les yeux et d’avoir pu creuser ensemble quelques approches possibles pour simplifier l’apprentissage des briques du Web.
The only reliable, widely used way to ensure impeccable software quality is to write less software that does less stuff, and then spend eons honing that tiny lot. Such an approach, however, is very rarely compatible with commercial success or even programmer motivations (despite what many may claim).
La route a été longue et difficile car les étudiants ont des exemples complètement inaccessibles, energivores et à l’expérience utilisateur désastreuse. Nous avons une certaine responsabilité à encenser ce genre de sites, les dégâts chez de nouveaux apprenants sont flagrants et toute la profession en pâtit.
Leftpad
Every package that you use adds yet another dependency to your project. Dependencies, by their very name, are things you need in order for your code to function. The more dependencies you take on, the more points of failure you have. Not to mention the more chance for error: have you vetted any of the programmers who have written these functions that you depend on daily?
J’étais en train de préparer cette intervention lorsque le fiasco leftpad est arrivé dans l’écosystème NPM. Du coup, j’ai eu immédiatement plein d’articles faisant une ode à la simplicité, à la réduction de dépendances et mettant en garde contre les couches d’abstraction. Merci Azer Koçulu, je pouvais difficilement rêver mieux :-). Je ne vais pas tirer sur l’ambulance mais ça illustre presque trop bien mon propos.
as your project progresses, your team’s productivity will drop because of all the complexity and dependencies. You’ll need more people to maintain it, and more people with specific knowledge to maintain it. If your lead developers leave, you’re dead. You should be fighting complexity and not embracing it. Every added framework, and even library, makes your project more difficult to maintain. Avoid unnecessary frameworks and libraries from day one.
Jusqu’où aller dans cette démarche ? Par où commencer ?
Burnout technique
Maybe it’s not too late for you, though. Perhaps, like me, you aren’t feeling particularly overworked. But are you feeling irritable, tired, and apathetic about the work you need to do? Are you struggling to concentrate on simple tasks?
Then maybe what you’re feeling is burnout, too.
J’ai travaillé pendant un an et demi avec Mozilla sur la partie paiement du Marketplace puis sur le site des extensions de Firefox. Et depuis un an avec Etalab sur la plateforme datagouv. Dans les deux situations, j’ai passé davantage de temps à lutter contre les outils plutôt qu’à les apprécier pour le travail rendu. C’est terrible car ceux-ci sont censés théoriquement faire gagner du temps mais sur le long terme cela se révèle être faux dans mon cas.
Je me demande si je ne suis pas en train de faire un burnout technique, non pas par trop de travail mais par manque de contrôle dans mes outils.
Je ferais probablement un article complet sur le sujet car c’est un gros morceaux et je manque encore de recul.
The aesthetic microlith
Growth for the sake of growth is the ideology of the cancer cell.
Edward Abbey
Toutes ces raisons m’ont amené à étudier une nouvelle piste. Cette appellation est une combinaison du Majestic Monolith (cache) et des microservices. Je me persuade qu’il y a une voie différente entre ces deux extrêmes. Une voie qui limite les fuites d’abstraction (cache) afin de réduire la dette technique et de favoriser l’inclusion de nouveaux membres dans une équipe. Une voie qui ne demande pas de réécrire la moitié de l’application tous les six mois car une nouvelle montée en version majeure n’est pas rétro-compatible. Une voie où l’on ne raisonne plus en termes de features et de bugs mais d’expérience utilisateur et de satisfaction pour l’ensemble des parties prenantes. Un environnement qui permet de faire une pause dans les développements afin de prendre le temps de davantage considérer les besoins des personnes qui utilisent le produit.
We all want things to be simpler. But we may not know what to sacrifice in order to achieve that goal.
Dans cette recherche de simplicité, j’ai essayé de remettre en question chaque concept de programmation, chaque bonne pratique, chaque bibliothèque, chaque ligne de code. J’ai essayé de produire un prototype qui soit un peu plus conséquent que celui proposé à Confoo pour voir jusqu’où cela pouvait aller. Ce qu’il me manque c’est non pas du temps de développement mais du temps de vie du projet pour analyser les effets produits sur le moyen terme. Je devrais avoir l’occasion d’expérimenter cela avec scopyleft prochainement, ça sent la trilogie.
À court terme en tout cas, c’est extrêmement plus fun à coder et l’on arrive au résultat finalement aussi rapidement. Cela devient une matière beaucoup plus malléable, dont on connait les forces et les faiblesses car le périmètre est réduit. En contrepartie, certains cas aux limites vont être écartés et l’expérience de certains utilisateurs se dégrade plus rapidement. Ce n’est pas que le coût de prise en compte soit énorme, il s’agit davantage de le prendre en considération lorsque le besoin est réel.
Budgets
L’utilisation de budgets m’a été rendue familière dans le domaine de la performance avec une répartition de différentes dépendances pour ne pas dépasser un certain seuil. J’essaye d’étendre le concept dans mes prototypes :
- Budget d’abstraction : ne pas dépasser 10 Mo pour son environnement Python ou Node par exemple. Ai-je bien compris les concepts sous-jacents de ces dépendances ? Comment un nouveau collaborateur va-t-il les comprendre ?
- Budget d’embarquement : pouvoir installer en trois commandes, lancer en une seule et lire la documentation sur une page unique. Est-ce que le fait de devoir découper la documentation n’est pas emblématique d’un trop grand nombre de fonctionnalités ?
- Budget de temps : une soirée de temps en temps, des interviews courtes (10 minutes), « une semaine de dev max ». Pourriez-vous recoder le cœur de votre produit en moins d’une semaine ?
- Budget de test : la documentation est test, l’interface est test, la possibilité de tout tester manuellement rapidement. Quelle est la latence de vos boucles de *feedback* ?
- Budget de LOC : au-delà de 5000 lignes de codes (incluant les dépendances !), le nombre de bugs potentiels (cache) devient ingérable (cache), analysez sur votre projet actuel à quel point il est difficile de s’y tenir !
Le point important de ces budgets ne réside pas tant dans la valeur choisie que dans la prise de recul que cela demande lorsqu’on atteint les limites. Est-ce que cette dépendance est vraiment nécessaire, est-ce que je suis prêt à retirer cette autre dépendance pour lui laisser la place, etc. Bien entendu, cette approche est critiquable et c’est ce qui fait tout l’intérêt de son expression et de vos réactions.
Élitisme
I call this kind of attitude the “Tea Party” of JavaScript development. The reason why we currently have JavaScript tooling fatigue is exactly because Tea Party developers insist on writing everything themselves instead of trying to build a better abstraction. The lesson here isn’t not fewer dependencies: it’s managing dependencies.
Il est certain que faire la cuisine demande un peu plus de savoir-faire que de faire réchauffer un plat cuisiné. On en revient ici à la problématique de l’enseignement mais aussi de la perte des développeurs ayant de l’expérience pour des tâches issues du management. La combinaison des deux donne une profession qui ne sait se servir que du micro-ondes car elle n’a même pas conscience de saveurs qu’elle n’a jamais expérimentée. Cette situation conduit à la prolétarisation du développeur et à la perte de ses savoirs.
En contrepartie, repartir de la base demande moins d’expérience en terme d’outillage. Pour continuer l’analogie, il n’est plus nécessaire de connaître une dizaine de marques de micro-ondes pour être capable de faire réchauffer un plat sans relire la notice : la source de chaleur est là, ça chauffe lorsqu’on approche un aliment.
Réinventer la roue
There’s nothing wrong with aesthetic enjoyment, and the joys of free software are many and varied. […] But these pleasures do not translate into political outcomes unless they are wedded to explicitly political activities.
Peut-être y a-t-il un acte politique dans la simplification de certaines briques. Celui de comprendre et d’être en capacité de transmettre. Celui de proposer des alternatives un peu moins mainstream mais finalement enrichissantes aussi, souvent dans d’autres domaines.
Réinventer la roue permet de comprendre pourquoi est-ce qu’il y a rotation et quelles sont les parties importantes. Il ne s’agit pas ici de savoir fondre une jante et de calculer le coefficient de friction de la gomme d’un pneu. Il ne s’agit pas tant de ré-interroger le « comment » que de creuser le « pourquoi ».
Passer à l’échelle
The cleaner and nicer the program, the faster it’s going to run. And if it doesn’t, it’ll be easy to make it fast.
Joshua Bloch
Les retours que j’ai eu lors de la précédente intervention portaient essentiellement là-dessus. Il se trouve qu’en choisissant des solutions minimalistes, elles sont bien souvent plus rapides et davantage interchangeables. Ce n’est pas toujours le cas car elles peuvent se révéler être plus spécifiques également.
Tout le monde semble obnubilé par un passage à l’échelle avant même d’avoir un premier utilisateur. Considérant que la plupart des projets échouent pour bien d’autres raisons, il serait peut-être temps de réévaluer l’intérêt de dimensionner immédiatement les nouveaux services pour encaisser une charge qui n’arrivera probablement jamais…
Les problèmes de performances sont vraiment des considérations de riches et doivent être traitées en fonction du besoin. Elles peuvent être anticipées dans le cas d’événements majeurs mais sinon un simple serveur suffit amplement sans avoir à imager, dockeriser, virtualiser, etc.
Stabilité
“Whatever new we do must make it possible for people to make a transition from old tools and ideas to new.” In this sense, software is less like a poem and more like a contract, a constitution, or a covenant. Software is history, organization, and social relationships made tangible.
Le problème actuel d’utiliser des outils minimalistes c’est qu’ils sont peu employés ce qui demande souvent un plus grand investissement dans les communautés concernées. C’est aussi le sentiment d’appartenir à un petit groupe dont tous les membres travaillent sur un bien commun et le modèlent à l’image de leurs besoins et de leurs aspirations. Le rythme de développement devient aussi plus raisonnable car le périmètre est réduit à dessein.
La stabilité d’une plateforme est aussi améliorée par le peu d’outils employés aux effets de bords non contrôlés. J’ai tellement d’exemples sur le sujet accumulés depuis ces quinze dernières années que cela pourrait faire l’objet d’un billet complet !
Maintenance
Capitalism excels at innovation but is failing at maintenance, and for most lives it is maintenance that matters more
*Innovation is overvalued. Maintenance often matters more* (cache)
Le problème ici c’est que je n’ai jamais rencontré de projet qui réduisent leur complexité dans le temps. Que ce soit via des itérations de retrait ou des réécritures complètes on arrive toujours à des usines à gaz si l’on ne s’est pas fixé en amont — de manière consentie par toutes les parties prenantes — les budgets évoqués plus haut. Pourtant en restant à l’échelle du microlith, la maintenance se trouverait potentiellement réduite de beaucoup.
Si l’on s’en tient à l’estimation selon laquelle la maintenance représente 67% d’un produit (cache), il devient important de trouver comment réduire ce coût.
Conclusion
There are only two hard things in Computer Science: knowing how to admit you’re wrong and apologizing when you are.
J’assume de pouvoir me tromper complètement sur le sujet. J’ai l’impression que la profession est en train de se scinder entre ceux qui suivent le rythme et ceux qui s’épuisent. Je propose ici une troisième voie qui me semble davantage soutenable tout en répondant à 80% du besoin et en utilisant des technologies récentes, il s’agit d’une descente créative chère aux adeptes de la permaculture.
Une forme de décroissance technique pour revenir aux fondamentaux sans pour autant s’en tenir à des expériences utilisateurs et développeurs de la décennie précédente.
Je n’ai pas l’impression d’être le seul dans ma démarche mais cela reste un mouvement minoritaire, ce qui est peut-être un atout. Là où les designers parlent de brutalité, j’évoquerais plutôt la frugalité avant même d’évoquer la composante éthique (cache) qui finie forcément par être chatouillée.
Discussions
Pas mal de réactions suite à l’intervention qui a plutôt été bien accueillie. Il s’agissait d’un public — plutôt SSII et plutôt familier avec Java — qui n’a pas forcément les mêmes contraintes que pour du développement web. Néanmoins, j’ai retenu quelques axes de discussion :
- De nombreuses questions et réactions ont portées sur l’enseignement, sur la manière de découvrir par soi-même les limites d’un framework dans le temps imparti par exemple. C’est un sujet à part entière qui mériterait peut-être un billet dédié ou une intervention (ParisWeb ?).
- La thématique des itérations de retrait avec la distinction entre retirer du code et retirer des fonctionnalités. Entre le faire au fil de l’eau et dédier une période à cela.
- Sur la dualité valeur pour l’utilisateur et fun pour le développeur, sachant qu’avec du fun le développeur va vraisemblablement être en mesure de produire de la valeur plus rapidement.
- Sur la capacité à avoir des métriques en fonction de la solution technique retenue. J’ai été assez inspiré par la keynote de Christian den Hartigh et sur son introduction de l’aléatoire dans les réponses. Peut-être qu’en choisissant aléatoirement une solution technique cela produirait d’autres résultats ?
- Sur la question économique de la simplicité, moins de fonctionnalités équivalant à moins de temps/argent/pouvoir pour les développeurs.
- Sur l’industrialisation qui n’est rendue possible qu’avec une stack figée et propre à l’entreprise plus qu’au besoin.
Et j’en oublie certainement d’autres, n’hésitez pas à expérimenter chez vous et à raconter vos propres histoires.