Alerte aux limites de l’effet Makefile

• L’effet Makefile désigne le fait de ne pas utiliser un outil complexe ou peu familier en repartant de zéro, mais de copier une configuration qui a déjà bien fonctionné puis de l’adapter à une nouvelle situation
• Au moment de résoudre un problème, réutiliser un exemple éprouvé peut constituer une réponse d’ingénierie rationnelle en réduisant le risque de bugs
• Mais du point de vue de la conception, cela peut aussi être vu comme un signal d’utilisabilité : l’outil est difficile ou pénible à utiliser dès le départ, si bien que les modifications s’accumulent sur des copies successives
• Un flux similaire de copie puis modification apparaît non seulement avec Make, mais aussi avec GitHub Actions, GitLab CI/CD, les configurations de linter et de formatter, ainsi que les systèmes de build
• Les concepteurs d’outils devraient vérifier si la configuration et la syntaxe propre sont vraiment nécessaires, s’il est possible de réutiliser des idiomes CLI familiers, et si les utilisateurs finissent par dépendre du copier-coller

---

Qu’est-ce que l’effet Makefile ?

• L’effet Makefile décrit le phénomène consistant, avec des outils présentant un certain niveau de complexité ou de nouveauté, à ne pas écrire une configuration depuis zéro mais à copier puis modifier un exemple antérieur « qui marchait bien »
• Le déroulé typique est le suivant
  • Il faut accomplir une tâche courante, et une tâche très similaire ou identique a déjà été réalisée auparavant
  • Make ou un outil comparable est choisi comme outil adapté à cette tâche
  • Au lieu d’écrire un nouveau Makefile, l’ingénieur copie le Makefile d’un travail précédent puis le corrige jusqu’à ce qu’il fonctionne dans le nouvel environnement
• Make n’est qu’un exemple emblématique ; selon les équipes et les personnes, les outils maîtrisés diffèrent, si bien que certaines familles d’outils sont plus exposées à cet effet que d’autres
• La plaisanterie du « heritage Makefile » désigne la situation où un Makefile transmis par un ingénieur senior, un professeur ou une autre personne est perpétué avec seulement de petites retouches

Les problèmes de conception d’outils révélés par la copie répétée

• Lorsqu’il faut résoudre un problème immédiatement, réutiliser un exemple fonctionnel peut être un choix concis
  • Comme la majeure partie du travail ne change pas, on peut en théorie introduire moins de nouveaux bugs
  • L’effet Makefile n’est pas en soi un phénomène mauvais ou inefficace
• Du point de vue de la conception, c’est un signal que l’outil, ou la manière de l’appliquer, est trop complexe ou trop fastidieux
  • Les utilisateurs copient sans cesse une solution existante au lieu de résoudre le problème depuis le début
  • Si cet effet apparaît dans des cas d’usage simples, l’outil est peut-être excessivement complexe pour cet usage
• Ce schéma apparaît aussi dans d’autres outils centrés sur la configuration que Make
  • Dans les configurations CI/CD, on copie souvent le YAML de GitHub Actions ou de GitLab CI/CD à partir de la dernière configuration fonctionnelle, puis on l’ajuste par itérations
  • Les configurations de linter et de formatter sont copiées d’un projet à l’autre à partir d’un ensemble de règles de base, puis durcies ou assouplies selon les contraintes locales
  • Les configurations non triviales des systèmes de build ont tendance à ressembler à celles des systèmes de build précédents

Les coûts en apprentissage, débogage et sécurité

• Les outils fortement touchés par l’effet Makefile peuvent freiner l’apprentissage large
  • Un petit nombre de personnes expertes configurent l’outil, tandis que les autres se contentent de copier et modifier en ne comprenant que les parties nécessaires
  • Le graphe de dépendances d’un système de build relève d’une complexité intrinsèque, mais devoir se souvenir de la différence entre $< et $^ dans Make n’en relève pas
• Quand le support de diagnostic et de débogage est insuffisant, les utilisateurs finissent par relancer l’outil plusieurs fois en ne récupérant que de petits indices
  • En CI/CD, cela conduit souvent à du débogage façon print, à travers le réseau et une couche intermédiaire d’orchestration de VM
• Le risque peut aussi augmenter sur le plan de la sécurité
  • Les mesures de sécurité exigent souvent de bien comprendre le « pourquoi » d’un comportement
  • Les systèmes où l’effet Makefile apparaît autorisent souvent une confusion entre code et données, ou plus généralement une confusion liée à la signalisation in-band
  • L’exemple représentatif est la template injection dans GitHub Actions

Les questions que les concepteurs d’outils devraient se poser

• Lorsqu’on crée un nouvel outil, il faut vérifier si les utilisateurs peuvent écrire une configuration depuis zéro, ou s’ils doivent absolument trouver un « exemple qui fonctionne » à copier
• Voici les questions à examiner
  • La configurabilité est-elle réellement nécessaire ?
  • Une syntaxe propre est-elle indispensable ?
  • Peut-on réutiliser la syntaxe et les idiomes familiers d’autres outils ou de la CLI ?
  • Les créateurs eux-mêmes finissent-ils par copier-coller les modes d’emploi, et si oui, est-il probable que les autres utilisateurs fassent de même ?
• Concernant le terme « cargo cult », l’article de Ken Shirriff explique pourquoi il s’agit d’un jargon inadapté

[GN⁺]

Avis sur Hacker News

• « Il s’avère invariablement qu’un système complexe qui fonctionne a évolué à partir d’un système simple qui fonctionnait. Un système complexe conçu à partir de zéro ne fonctionne jamais, et on ne peut pas le rafistoler pour le faire fonctionner. Il faut recommencer avec un système simple qui fonctionne »
  — John Gall (1975), Systemantics: How Systems Really Work and How They Fail
  https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law

  • C’est pourquoi je suis toujours sceptique face aux nouveaux langages et frameworks. Ils peuvent avoir fière allure dans des slides PowerPoint, mais on ne sait pas bien à quoi ils ressembleront dans un système complexe maintenu sur la durée
    En général, des fonctionnalités façon rustines commencent à s’ajouter pour gérer des cas particuliers, et cela ressemble au signe que ce genre d’exceptions va continuer à se multiplier indéfiniment
    Il y a une différence subtile mais importante entre « appliquer l’expérience acquise » et « concevoir un tout nouveau système autour d’un point qui vous agace personnellement »

• J’ai une autre hypothèse. Environ 10 % des développeurs comprennent réellement les principes et peuvent démarrer quelque chose de zéro, et 40 % supplémentaires peuvent faire leur travail quotidien en copiant-collant depuis du code local, Stack Overflow, GitHub ou des LLM, tout en comprenant à peu près ce qui se passe
  Les 50 % restants ne savent pas grand-chose au-delà de quelques puzzles LeetCode, et ne comprennent pas vraiment ce qu’ils copient-collent
  Avec une telle répartition, il est probable que plus de la moitié des Makefile soient des bouts copiés-collés qui fonctionnent plus ou moins. S’ils viennent d’un endroit où cela fonctionnait déjà, le travail est fait et on passe au ticket suivant
  Je ne blâme pas l’outil lui-même. Les Makefile sont bien connus et ne sont pas verbeux pour les petits projets. Pour un monstre de 10 000 fichiers, cela peut être un mauvais choix, mais j’ai déjà vu des Makefile propres même dans de très gros projets. Ce ne serait pas mon premier choix personnellement, mais j’aime les Makefile et je les utilise sporadiquement depuis plus de 30 ans

  • Ce que les gens ignorent, c’est souvent parce qu’ils n’ont pas le temps de le découvrir, à mon avis. Le nombre de batailles que l’on peut mener dans une journée est limité
    Par exemple, quand un programmeur C++ traite un ticket, jusqu’à combien de couches de la stack doit-il comprendre ? Doit-il connaître jusqu’aux noms des registres CPU ? Jusqu’où doit aller un chercheur en IA qui n’utilise que Jupyter ? Il est recommandé d’apprendre au maximum ses outils et sa stack, mais le temps est limité
  • Utiliser un Makefile très simple même pour un projet de 10 000 fichiers est en réalité trivial. La plupart des Makefile que j’ai vus dans des projets open source étaient bien plus compliqués que de bons Makefile
    Quand je vois dans un Makefile des règles individuelles pour produire un seul fichier précis, c’est presque toujours une erreur à mes yeux
    En général, il ne devrait y avoir que des règles de build génériques servant à construire tous les fichiers d’un type donné
    Un Makefile ne devrait presque jamais contenir de liste de fichiers source ni de liste de dépendances, seulement la liste des répertoires où se trouvent les sources
    Make devrait parcourir les répertoires source pour trouver les fichiers, les classer par type, établir la liste des dépendances et appeler les règles de build appropriées. Au moins avec GNU make, c’est très simple et c’est même indiqué dans le manuel utilisateur
    Écrit ainsi, que le projet comporte 1 fichier ou 10 000, l’effort pour créer ou modifier le Makefile reste tout aussi négligeable. Il n’est pas non plus nécessaire de mettre à jour le Makefile à chaque création, renommage, déplacement ou suppression de fichier source
  • J’aime les Makefile, mais je ne les utilise que pour mon usage personnel. À chaque nouveau projet personnel, j’ajoute un Makefile à la racine, même si la cible n’est rien de plus que le build le plus basique du langage concerné
    Parce que chaque langage et framework a un « ordre » de build différent, et qu’il est impossible de tout retenir. Mais $ make, c’est facile
  • Je pense qu’il y a une vraie différence entre savoir configurer quelque chose et comprendre réellement comment cela fonctionne
    Je suis d’accord pour dire que beaucoup de développeurs d’apps productifs seraient incapables de configurer un nouveau projet à partir de zéro, mais c’est souvent moins une question de compréhension profonde qu’une question de connaître les bonnes règles magiques et incantations pour faire fonctionner plusieurs outils ensemble

• Un autre facteur que j’ai observé au travail concerne les outils et systèmes que les développeurs devront bien manipuler un jour, mais qu’ils estiment peu utile d’apprendre au quotidien
  Par exemple, les systèmes de build et la configuration de CI. Ils sont indispensables, mais les développeurs ne pensent pas devoir s’en occuper tous les jours. La CI est vue comme un système qu’on « configure puis oublie », et la réaction est souvent : faut-il vraiment apprendre tout ça pour builder une appli ?
  Les développeurs s’attendent à ce que « ça marche, tout simplement » et, s’il y a de la complexité, considèrent qu’une autre équipe — des gens comme moi — s’en charge. Ainsi, chaque fois qu’un développeur doit toucher à ce système, il est fortement incité à copier la dernière configuration qui marchait, puis à retourner à son « vrai » travail
  La meilleure solution consiste à faire un compromis avec les développeurs. Fournir des outils simples ou complexes selon la tâche, disposer d’une documentation, et minimiser la croyance en une forme de « magie ». Des outils comme Make ont tendance à échouer sur ce point, car ils paraissent trop complexes et trop opaques

  • Le gros problème de la configuration de CI, à mon avis, ressemble généralement à ceci : c’est lent, propriétaire, cela manipule des secrets qui limitent les personnes autorisées à travailler dessus, et, le plus souvent, on ne peut pas l’exécuter en local
    Le cycle de feedback devient donc extrêmement long, et le travail lui-même devient très pénible
  • Le meilleur flux que j’aie vu consistait à utiliser la CI/CD comme un wrapper très mince autour de scripts ou d’un Makefile présents dans le dépôt
    Si un développeur peut exécuter en local une partie ou la totalité des tâches de « CI/CD », il peut voir, contrôler et comprendre ce qui se passe. Cela aide beaucoup à donner un sentiment de propriété et de sécurité, au lieu de l’impression que « la CI/CD, c’est un autre monde »
    Cela ne marche pas toujours. J’ai déjà vu une équipe de deux personnes, pourtant dotée d’une CI/CD en wrapper mince, la traiter comme un processus extraterrestre et refuser d’y toucher
  • La machine à café du bureau n’est pas non plus un objet qu’on « configure puis oublie », mais on ne s’attend pas à ce que toutes les personnes qui l’utilisent partagent à parts égales la responsabilité de sa maintenance
    De la même manière, la CI a besoin d’un propriétaire, et faire retomber la responsabilité sur le dernier développeur qui a voulu s’en servir n’est pas une façon efficace de travailler
  • Make est l’un des outils de build les plus simples. Comparé à des outils comme Grunt ou Webpack, il ressemble davantage à un marteau qu’à une foreuse minière
    La solution consiste à ne pas adopter les outils utilisés par les grandes entreprises au seul motif qu’elles les utilisent. Ce sera sans doute une opinion impopulaire, mais je pense que la CI/CD n’est pas nécessaire dans la plupart des endroits où elle est employée
    Même si cela ajoute quelques étapes, il faut trouver une façon de builder et de déployer en réduisant absolument au minimum le nombre de pièces mobiles. Ensuite, il faut évaluer soigneusement le coût de l’automatisation de telle ou telle partie. Introduire un gros système pour faire quelque chose de simple n’a généralement pas de valeur à long terme
    Si vous avez vraiment besoin de CI/CD, vous le saurez parce qu’il y aura un point de douleur. Si ce système fait souffrir les développeurs, ce n’est pas le bon outil
  • Si make vous semble « trop complexe et trop opaque », c’est que vous n’avez pas encore vu cmake

• Make et les Makefiles sont extrêmement simples quand ils ne sont pas générés automatiquement par autoconf. S’ils ont été produits par autoconf, il ne faut pas les modifier : ce sont des artefacts de build. Dans la mesure du possible, il vaut mieux aussi abandonner autoconf
  Plus largement, cet effet existe bel et bien. On peut le subir, ou l’exploiter. La façon de l’exploiter est la suivante : écrire un peu de code, ou le copier-coller depuis quelque part, l’utiliser dans un projet, puis l’ajuster selon les besoins. Au démarrage du projet suivant, recopier ce code et le modifier pour l’adapter à ce deuxième projet. Voir si les changements peuvent être réappliqués au projet d’origine. Si les deux fonctionnent et restent synchronisés, extraire ce code pour en faire une bibliothèque. Parfois, il faut davantage de projets pour le raffiner jusqu’à obtenir quelque chose qui ressemble vraiment à une bibliothèque. Dans le meilleur des cas, on le publie en open source pour que d’autres puissent aussi l’utiliser

  • Les Makefiles sont aussi extrêmement limités. Le calcul de fraîcheur basé sur les horodatages se casse souvent avec les systèmes modernes de gestion de versions
    Git n’enregistre pas les horodatages en interne ; le mtime d’un fichier peut donc être mis à jour même si son contenu est identique, et c’est effectivement fréquent, ce qui provoque des rebuilds inutiles
    Ils gèrent aussi très mal les outils modernes dont l’entrée ou la sortie est un répertoire entier, ou les outils dont on ne connaît pas les noms de sortie avant l’exécution
    J’aime make, je l’ai bien utilisé malgré ses défauts, et je connais les contournements, ainsi que les contournements de ces contournements. Mais dès qu’un outil ne correspond plus parfaitement aux attentes de make, la difficulté et la complexité de produire un Makefile correct grimpent très vite
  • Les Makefiles sont simples, mais très souvent faux. Écrire un Makefile qui fonctionne correctement autrement que dans le cas d’un « build depuis zéro » est étonnamment difficile
    Ce n’est pas une blague. L’existence même du concept de make clean en est une preuve décisive

• Le Makefile est peut-être une mauvaise analogie. Le problème que la plupart des gens rencontrent avec les Makefiles vient du fait qu’ils en écrivent trop rarement. Ils ont une idée générale de ce que fait make, mais pas la mémoire musculaire nécessaire pour en écrire un depuis zéro
  Cela dit, le fond est juste. J’ai souvent vu beaucoup de code mort, jamais réellement utilisé, rester dans du code copié depuis le Web. Une bonne habitude consiste à supprimer des choses jusqu’à ce que ça casse, puis à ne rétablir que la partie qui a cassé. Il faut supprimer autant que possible, et supprimer à coup sûr tout ce qui n’est pas utilisé actuellement

  • On rencontre le même problème avec de nombreux outils : Makefiles, configuration KVM, configuration Docker, pipelines CI/CD, etc.
    Jusqu’ici, ma solution a consisté à créer un dépôt séparé rassemblant des notes et des exemples de programmes en scripts shell pour ces outils, bibliothèques et frameworks
    Chaque fois que je dois réutiliser un outil, je consulte mes notes pour me rafraîchir la mémoire, et je les mets à jour quand j’apprends quelque chose de nouveau. Désormais, je peux aussi pointer un LLM vers ce dépôt et lui poser des questions
    Ce dépôt est personnel et contient des informations sur des outils accessibles publiquement. Les connaissances propres à une organisation sont conservées dans un dépôt similaire mais séparé, puis supprimées lorsque mon contrat avec un client ou un employeur prend fin

• Le terme qui décrit le mieux ça, c’est développement cargo cult. Le cargo cult est apparu dans le Pacifique pendant la Seconde Guerre mondiale : des insulaires autochtones avaient vu ces avions presque miraculeux apporter nourriture, alcool et matériel, et se sont mis à imiter les gestes des militaires, en priant pour que des avions en bambou et des dispositifs en noix de coco impressionnent les dieux et fassent revenir les cargaisons.
  Le problème, c’est que les insulaires ne comprenaient pas la science derrière les avions, les radios ou les fusils.
  De la même façon, un développeur façon cargo cult voit les résultats possibles mais ne comprend pas les premiers principes ; il imite les gestes des grands prêtres de la technologie en espérant pouvoir copier leur réussite.
  Résultat : il copie, colle, essaie, bidouille, cherche, tire, pousse et ajuste en boucle, en espérant que cette fois, ça marchera à peu près, ne serait-ce que sur un jeu de données précis un mardi soir.

  • Je ne vois pas ça comme du développement cargo cult. Le cargo cult consiste plutôt à imiter sans comprendre une pratique qui ne fonctionnait que dans un contexte plus large, alors même que ce contexte a disparu.
    En pratique, on répète des gestes ou des rituels qui n’ont aucun effet en eux-mêmes, en espérant obtenir les résultats qu’une autre entreprise avait obtenus en accomplissant les mêmes rituels.
    Ce dont parle l’article original est différent. Ce qui est copié, le code, a un effet en lui-même. On peut le tester et déterminer s’il fonctionne.
    Cette distinction est importante. Comme les symptômes de l’effet Makefile décrit dans l’article et ceux du cargo cult sont différents, les traiter comme identiques rend le diagnostic plus difficile. Dans le cargo cult, on perd du temps sur des choses qui ne fonctionnent pas réellement, par superstition. Dans l’effet Makefile, le fonctionnement est prouvé, mais des morceaux semblables à des organes vestigiaux sont copiés, ce qui rend progressivement la maintenance plus difficile.
  • Je suis l’auteur de l’article. Ce point figure dans la note 1.
    Plus précisément, je ne pense pas que ce soit exactement la même chose que le cargo cult. Le cargo cult implique un manque de compréhension. Mais on peut très bien comprendre un système et pourtant vivre principalement par copier-coller, parce que la complexité intrinsèque de ce système y pousse. C’était le cœur de l’article.
  • Je copie-colle souvent des choses que j’ai moi-même écrites par le passé. C’est le cas quand un outil est trop pénible et que le coût du changement de contexte cognitif est difficile à supporter.
    En général, je comprends ce qui se passe en interne, mais le simple fait de passer dans ce « mode » est cognitivement lourd, donc je l’évite si possible.
    Les outils qui entrent dans cette catégorie sont souvent des outils d’exploitation comme CI/CD, k8s ou Docker : une complexité énorme, alors que ce n’est pas le problème central que je cherche à résoudre. Make, en particulier, rend difficile d’éviter ce changement de contexte, donc aujourd’hui j’ai plutôt tendance à l’éviter tout court.
    Ça n’a rien à voir avec une formule magique, et je sais quel compromis je fais. Mais il y a quand même un risque que cela se transforme en effet Makefile.
  • L’article en parle aussi dans une certaine mesure dans la note 1 :
    « L’effet Makefile ressemble à d’autres phénomènes, comme le cargo cult, la normalisation de la déviance ou les “langages en écriture seule”. Dans cet article, je soutiendrai qu’il en diffère légèrement, car il ne s’agit pas de quelque chose d’intrinsèquement inefficace ou mauvais, mais des conséquences d’une conception particulière. »
  • J’ai l’impression que ma compréhension de la programmation est proche du niveau « débutant parmi les débutants ». Dans ce cas, pour éviter une mentalité de « cargo cult », faut-il un parcours structuré du type enseignement → apprentissage → mise en pratique → échec → répétition ?
    Alors, si quelqu’un veut vraiment « quitter l’île et piloter l’avion », est-ce qu’au fond l’université est la voie la plus proche du « vrai » ?
    Je sais qu’il est difficile d’être catégorique, qu’il existe beaucoup d’exceptions, et que chacun a diverses façons de justifier « moi, je ne peux pas faire ça ». Ici, je pose la question du point de vue de la théorie optimale. Le chemin optimal pour éviter les comportements de culte consiste à comprendre l’ensemble, et cet « ensemble » ne vient-il pas de l’enseignement supérieur ?
    Logiquement, même si l’on étudie sérieusement avec des livres pour atteindre ou dépasser la « complétude » de l’université, il semble qu’il manquera quelque chose, d’une certaine manière, par rapport au temps passé avec des enseignants compétents et en salle de classe. Même en supposant que la même personne travaille aussi dur dans les deux cas.

• Un autre facteur est la fréquence d’utilisation. J’écris de gros textes en LaTeX une fois par an tout au plus.
  Le niveau de LaTeX que j’utilise n’est pas un outil difficile, mais si je ne m’en sers que quelques semaines par an, je ne peux absolument pas me souvenir des détails d’utilisation ; donc je commence généralement un nouveau document en copiant-collant un document précédent.

  • Pour les technologies que j’utilise relativement souvent, comme les Makefile et les scripts shell, j’essaie de les apprendre afin d’éviter l’« effet Makefile ».
    Mais avec LaTeX, même si je l’ai énormément utilisé par le passé, j’ai toujours copié-collé depuis des modèles. C’était encore pire pour les présentations beamer et les schémas TikZ : je copiais depuis une présentation ou un dessin précédent plutôt que depuis un modèle.
    Pour TikZ, je considère que l’outil lui-même est intrinsèquement complexe et que je ne l’ai pas assez appris.
    Pour LaTeX, je pense l’avoir suffisamment appris, donc il peut y avoir une autre raison.
    À mon avis, cela peut être un problème de valeurs par défaut normales. Un bon outil devrait fournir de bonnes valeurs par défaut. Mais selon ce critère, LaTeX n’est pas un bon outil. Mes documents commencent en général comme ceci :

    \documentclass[paper=a4, DIV9, 12pt, abstracton, headings=normal,  
    captions=tableheading]{scrartcl}  
    \usepackage[T1]{fontenc}  
    \usepackage[utf8]{inputenc}  
    \usepackage[english,german,ngerman]{babel}  
    \usepackage[english,german]{fancyref}  
    % ...  
    \usepackage{microtype}  
    \usepackage{hyperref}  
    

    La plupart de ces lignes servent à obtenir une prise en charge de base correcte du non-ASCII nécessaire à ma langue maternelle, ou à activer des valeurs par défaut normales comme le papier A4 et microtype. Avec des outils modernes comme pandoc/Markdown, cela pourrait ne pas être nécessaire.
    Donc, quand on copie-colle ce genre de choses, c’est souvent pour obtenir les bonnes valeurs par défaut qu’un meilleur outil aurait fournies dès le départ.
  • J’utilise LaTeX plus souvent, mais moi aussi je commence avec un en-tête copié-collé. Il contient les packages nécessaires pour ma langue (fontenc, babel, package de composition local), les packages presque toujours nécessaires comme graphicx/fancyhdr/hyperref/geometry, ainsi que des définitions de symboles et de noms utiles dans mon domaine.
    À moins de ne pas faire de maths ou de n’écrire que du texte brut en anglais, LaTeX est assez proche du « piles non incluses ».

• C’est du développement piloté par le copier-coller [0], et ce n’est pas un sujet propre aux Makefiles. Cela concerne toute l’industrie, qui copie du code un peu partout sans même savoir ce qu’elle copie.
  Honnêtement, je pense que Copilot a aggravé le phénomène, parce qu’on accepte les yeux fermés des blocs de code dans les codebases.
  [0] https://andrew.grahamyooll.com/blog/copy-pasta-driven-develo...

  • Il faut blâmer les gens côté business. J’ai essayé, au moins 7 fois d’affilée probablement, de devenir expert de make, mais on ne m’a jamais laissé le temps de le manipuler tous les jours jusqu’à l’avoir complètement en tête.
    À un moment, j’ai simplement abandonné. Ça devient une connaissance ésotérique qu’on ne peut pas ancrer dans la mémoire musculaire, et qu’il faut réapprendre depuis le début chaque fois qu’on en a besoin. Je suis donc passé à des outils plus simples.
    La perte du travail en profondeur n’est pas la faute des bons programmeurs, mais celle des gens côté business.

• J’ai trop souvent vu des Makefiles copiés tels quels depuis d’autres projets, puis modifiés pour “fonctionner”, tout en conservant des étapes de build et des cibles inutiles n’ayant absolument aucun rapport.
  Personnellement, ça m’agace beaucoup.

  • S’il n’y a absolument aucune documentation, comment savoir ce qui est pertinent ou non ?
    Par essais et erreurs ? Alors amuse-toi bien :p

• Il y a certes beaucoup d’outils plus complexes que nécessaire, mais je ne pense pas que Make lui-même soit un bon exemple de cela.
  Avec les outils modernes, les problèmes de complexité sont souvent aggravés par une documentation insuffisante, une documentation façon livre de recettes, une documentation qui n’explique pas le modèle conceptuel nécessaire pour raisonner sur le fonctionnement de l’outil, ou l’absence de spécification suffisamment détaillée et exacte.
  Ce n’est pas le cas de Make. Il est bien documenté et, si l’on prend réellement le temps de lire la documentation, il n’est pas difficile à comprendre.
  L’approche façon livre de recettes décrite plus haut mène à une culture qui sous-estime l’importance d’apprendre et de comprendre les outils qu’on utilise, ainsi que celle d’une documentation rigoureuse qui rend cela possible. Ou peut-être que le lien de causalité est inverse.
  Dans tous les cas, je pense que le problème est qu’on consacre trop peu de temps à produire une documentation d’outil exhaustive et à jour, trop peu d’efforts à concevoir les outils de manière à rendre une telle documentation possible dès le départ, et trop peu de ressources à enseigner et apprendre les outils nécessaires.