Les lois du génie logiciel

• Une collection rassemblant en un seul endroit 56 principes et patterns qui influencent les systèmes logiciels, les équipes et la prise de décision, couvrant un large éventail de sujets allant du fonctionnement des équipes à l’architecture, la qualité, la conception et la prise de décision
• Les lois liées aux équipes, comme la loi de Conway, la loi de Brooks ou le nombre de Dunbar, montrent que la structure organisationnelle influence directement la conception des systèmes et la productivité
• Côté architecture, la loi de Hyrum, le théorème CAP, la loi de Gall, entre autres, recensent les contraintes et principes à prendre impérativement en compte lors de la conception de systèmes complexes
• Les lois liées à la qualité traitent des difficultés concrètes du maintien de la qualité du code et du débogage, notamment la dette technique, la pyramide des tests et la loi de Kernighan
• Dans le domaine de la prise de décision, on retrouve l’effet Dunning-Kruger, le biais des coûts irrécupérables, le principe de Pareto et d’autres repères sur les biais cognitifs et critères de jugement dans lesquels on tombe facilement pendant le développement

---

Équipes (Teams)

1. Loi de Conway (Conway's Law)

> Les organisations conçoivent des systèmes qui reproduisent fidèlement leur structure de communication

• L’architecture logicielle a naturellement tendance à suivre la structure de communication de l’organisation qui l’a produite
• Si une équipe est divisée en 3 groupes, le système tend lui aussi à se diviser en 3 grands modules
• Il existe aussi une « stratégie Conway inversée » (Inverse Conway Maneuver), qui consiste à exploiter cette idée à l’envers : réorganiser d’abord la structure des équipes en fonction de l’architecture souhaitée
• Lors de l’adoption des microservices, il est efficace d’aligner les frontières des équipes sur celles des services

2. Loi de Brooks (Brooks's Law)

> Ajouter des personnes à un projet logiciel en retard le retardera encore davantage

• Quand de nouveaux arrivants rejoignent l’équipe, les membres existants consacrent du temps à la formation et à la coordination, ce qui réduit temporairement la productivité globale
• Quand l’effectif augmente, les canaux de communication augmentent de façon exponentielle (pour n personnes : n(n-1)/2)
• Frederick Brooks l’a formulée dans son livre de 1975 The Mythical Man-Month, à partir de son expérience sur le projet IBM OS/360
• La loi de Little (L = λ × W) permet de l’expliquer quantitativement : quand on ajoute des personnes, le WIP (travail en cours) augmente, mais le throughput stagne, ce qui allonge au contraire le lead time
• La solution n’est pas d’ajouter du personnel, mais d’ajuster le périmètre ou de modifier le calendrier

3. Nombre de Dunbar (Dunbar's Number)

> La limite cognitive des relations qu’une personne peut entretenir de manière stable est d’environ 150 personnes

• Valeur dérivée par Robin Dunbar à partir de la corrélation entre la taille du cerveau des primates et celle de leurs groupes sociaux
• Hiérarchie sociale de Dunbar : ~5 personnes (relations intimes), ~15 (collaborateurs de confiance), ~50 (relations de travail proches), ~150 (liens sociaux stables)
• Quand une organisation d’ingénierie dépasse 150 personnes, la communication informelle atteint ses limites, ce qui rend nécessaires des hiérarchies et des processus formels
• La « Two-Pizza Team » d’Amazon (5 à 10 personnes) reflète le fait que, même au sein d’un groupe de 150 personnes, la collaboration effective se fait à plus petite échelle

4. Effet Ringelmann (The Ringelmann Effect)

> Plus la taille d’un groupe augmente, plus la productivité individuelle diminue

• Phénomène de « paresse sociale » (social loafing) où la contribution de chaque individu diminue à mesure que le groupe grandit
• Dans les équipes logicielles aussi, l’augmentation de la taille de l’équipe dilue la responsabilité individuelle et accroît les coûts de coordination
• Explique pourquoi les petites équipes produisent davantage par personne

5. Loi de Price (Price's Law)

> Un nombre de personnes égal à la racine carrée du nombre total de participants réalise 50 % du travail total

• Dans une organisation de 100 personnes, environ 10 assurent la moitié du travail total
• Plus l’organisation grandit, plus la dépendance à un petit nombre de profils très performants s’accentue
• Explique pourquoi la productivité n’augmente pas linéairement quand on agrandit une équipe

6. Loi de Putt (Putt's Law)

> Ceux qui comprennent la technologie ne dirigent pas, et ceux qui dirigent ne comprennent pas la technologie

• Formulation satirique du décalage entre rôle managérial et expertise technique dans les organisations techniques
• Lors de la conception d’une structure de leadership technique, il faut reconnaître cet écart et prévoir des mécanismes de compensation

7. Principe de Peter (Peter Principle)

> Dans une organisation, tout employé tend à être promu jusqu’à atteindre son niveau d’incompétence

• Schéma dans lequel une personne compétente dans un rôle est promue et devient incompétente dans son nouveau rôle
• Reflète la réalité selon laquelle un excellent développeur ne devient pas nécessairement un bon manager
• D’où la nécessité d’un système de double filière séparant la filière IC (Individual Contributor) et la filière management

8. Bus Factor

> Le nombre minimal de départs dans l’équipe pouvant mettre un projet en grave danger

• Si le Bus Factor est de 1, cela signifie la présence d’un Single Point of Failure
• Il est important d’augmenter le Bus Factor grâce au partage des connaissances, au pair programming et à la documentation
• Les code reviews et le cross-training sont des moyens concrets d’améliorer le Bus Factor

9. Principe de Dilbert (Dilbert Principle)

> Les entreprises ont tendance à promouvoir les employés incompétents à des postes de management afin de limiter les dégâts

• Observation satirique proposée par Scott Adams, variante du principe de Peter
• Phénomène organisationnel paradoxal où les postes de management sont perçus comme ceux où l’on peut faire le moins de dégâts opérationnels

---

Planification (Planning)

10. Optimisation prématurée / principe d’optimisation de Knuth (Premature Optimization)

> L’optimisation prématurée est la racine de tous les maux

• Donald Knuth l’a formulé dans un article de 1974 : « dans environ 97 % des cas, les petits gains d’efficacité doivent être ignorés »
• Comme environ 20 % du code représentent 80 % du temps d’exécution, optimiser les 80 % restants est du gaspillage
• Le bon ordre : d’abord faire fonctionner, puis faire correctement, puis rendre rapide si nécessaire
• Le code optimisé étant plus complexe, il faut d’abord vérifier les véritables goulets d’étranglement au moyen du profiling avant d’optimiser

11. Loi de Parkinson (Parkinson's Law)

> Le travail s’étend jusqu’à occuper tout le temps disponible

• Si l’échéance est de 2 semaines, le travail prend 2 semaines ; si elle est de 4 semaines, il s’étale sur 4 semaines
• Cela explique pourquoi il est important de définir des jalons courts et clairs dans les projets logiciels
• L’agilité basée sur les sprints constitue une réponse concrète à cette loi

12. Règle du 90-90 (The Ninety-Ninety Rule)

> Les premiers 90 % du code prennent 90 % du temps de développement, et les 10 % restants prennent encore 90 % du temps

• Met en garde sur le fait que les 10 % finaux d’un projet logiciel (cas limites, polissage, correction de bugs) prennent bien plus longtemps que prévu
• Dire qu’un produit est « presque terminé » peut en réalité signifier qu’on n’en est qu’à la moitié du planning total

13. Loi de Hofstadter (Hofstadter's Law)

> Cela prend toujours plus de temps que prévu, même si l’on tient compte de la loi de Hofstadter

• Loi à structure auto-référentielle et récursive, qui exprime la difficulté intrinsèque de l’estimation des délais en logiciel
• Même en ajoutant de la marge, le planning est encore dépassé dans la réalité
• Présentée par Douglas Hofstadter dans son livre de 1979 Gödel, Escher, Bach

14. Loi de Goodhart (Goodhart's Law)

> Lorsqu’un indicateur devient un objectif, il cesse d’être un bon indicateur

• Exemple typique : définir la couverture de code comme KPI conduit à produire des tests sans réelle valeur
• Mesurer la productivité en lignes de code (LOC) encourage à produire du code inutilement verbeux
• Il faut se concentrer non sur l’optimisation des métriques, mais sur l’atteinte de la valeur réelle

15. Loi de Gilb (Gilb's Law)

> Quand une quantification est nécessaire, toute forme de mesure vaut mieux que l’absence de mesure

• Même si une mesure parfaite est impossible, une mesure approximative est toujours plus utile que pas de mesure du tout
• S’applique aussi à des éléments difficiles à quantifier, comme la qualité logicielle ou la satisfaction utilisateur

---

Architecture

16. Loi de Hyrum (Hyrum's Law)

> Dès qu’une API a suffisamment d’utilisateurs, quelqu’un dépendra de chacun des comportements observables du système

• Au-delà de la seule spécification officielle de l’API, des comportements non officiels comme le timing, le format des messages d’erreur ou l’ordre de tri deviennent eux aussi des dépendances
• Exemple de Microsoft Windows, qui a conservé des comportements d’anciennes versions pour rester compatible avec des applications tierces dépendant de comportements non documentés et de bugs
• Observation faite par Hyrum Wright chez Google vers 2011-2012, à partir d’expériences de modification de bibliothèques internes
• Son collègue Titus Winters lui a donné le nom de "loi de Hyrum" (Software Engineering at Google)
• Le contrat réel n’est pas l’API officielle, mais l’ensemble des comportements effectivement observables

17. Loi de Gall (Gall's Law)

> Un système complexe qui fonctionne est nécessairement le résultat de l’évolution d’un système simple qui fonctionnait déjà

• Concevoir un système complexe dès le départ augmente fortement le risque d’échec, car il y a trop de variables inconnues et non validées
• Fondement théorique de l’approche MVP (Minimum Viable Product)
• Exemple de Facebook, qui a commencé en 2004 comme un simple système de profils pour les étudiants de Harvard avant de s’étendre progressivement
• Même lors d’une migration vers des microservices, il est préférable de partir d’un monolithe puis de le découpler progressivement
• Formulée par John Gall dans son livre Systemantics en 1975 (devenu un ouvrage culte après avoir été refusé par 30 éditeurs)

18. Loi des abstractions perméables (The Law of Leaky Abstractions)

> Toute abstraction non triviale fuit dans une certaine mesure

• Cas typique : un ORM masque SQL, mais en cas de problème de performance, il faut malgré tout inspecter les requêtes réellement générées
• Le garbage collection en Java/Python est lui aussi une abstraction, mais des comportements internes comme les pauses du GC ont un impact sur les performances
• La leçon n’est pas que l’abstraction est mauvaise en soi, mais qu’il faut prévoir ce qui se passe lorsqu’elle se fissure
• Présentée par Joel Spolsky dans un billet de blog en 2002 avec des exemples autour de TCP, de la mémoire virtuelle, etc.
• Fait aussi écho à la formule de George Box : "Tous les modèles sont faux, mais certains sont utiles"

19. Loi de Tesler / loi de conservation de la complexité (Tesler's Law)

> Toute application possède une complexité intrinsèque irréductible : on peut la déplacer, mais pas l’éliminer

• Question centrale : qui va supporter la complexité (l’utilisateur ou le système)
• Calendly absorbe dans le système la complexité de la coordination des rendez-vous, alors qu’un fil d’e-mails la reporte sur l’utilisateur
• Une bonne conception déplace la complexité de l’expérience utilisateur vers l’intérieur du système
• Principe formalisé par Larry Tesler dans les années 1980 lors de son travail sur Apple Lisa et les premières interfaces graphiques

20. Théorème CAP (CAP Theorem)

> Un système distribué ne peut garantir que deux propriétés parmi la cohérence (C), la disponibilité (A) et la tolérance au partitionnement (P)

• Les partitions réseau étant inévitables dans le monde réel, le vrai choix se fait en pratique entre cohérence et disponibilité
• Systèmes CP (ex. : MongoDB) : en cas de partition, les écritures sont bloquées pour maintenir la synchronisation de toutes les réplicas
• Systèmes AP (ex. : Cassandra, DNS) : ils continuent à répondre pendant la partition et tolèrent des incohérences temporaires entre réplicas
• Proposé par Eric Brewer en 2000 dans le contexte des services web, puis démontré formellement par Gilbert & Lynch en 2002

21. Effet du second système (Second-System Effect)

> Après un petit système couronné de succès, on a souvent tendance à produire un système successeur surconçu et hypertrophié

• Schéma classique : fort du succès du premier système, on déverse toutes ses idées dans le deuxième
• Les causes principales sont la surcharge fonctionnelle (feature creep) et la surgénéralisation (over-generalization)
• Identifié par Frederick Brooks dans The Mythical Man-Month

22. Les erreurs de l’informatique distribuée (Fallacies of Distributed Computing)

> Huit hypothèses erronées fréquemment faites par ceux qui conçoivent un système distribué pour la première fois

• Les 8 erreurs : (1) le réseau est fiable, (2) la latence est nulle, (3) la bande passante est infinie, (4) le réseau est sûr, (5) la topologie ne change pas, (6) il n’y a qu’un seul administrateur, (7) le coût de transport est nul, (8) le réseau est homogène
• Concevoir un système sur la base de ces hypothèses conduit en production à des pannes inattendues et à des problèmes de performance

23. Loi des conséquences imprévues (Law of Unintended Consequences)

> Toute modification d’un système complexe doit faire anticiper des conséquences inattendues

• Modifier un composant d’un système peut produire des effets de bord dans des zones impossibles à prévoir
• Principe qui justifie la nécessité du chaos engineering et de tests exhaustifs

24. Loi de Zawinski (Zawinski's Law)

> Tout programme tente de s’étendre jusqu’à pouvoir lire les e-mails

• Satire du phénomène de gonflement fonctionnel (feature bloat) : à mesure qu’un logiciel réussit, on veut lui ajouter toujours plus de fonctions
• Observation attribuée à Jamie Zawinski (développeur des débuts de Netscape)
• Mise en garde contre la tendance des outils simples à vouloir devenir, avec le temps, des plateformes à tout faire

---

Qualité (Quality)

25. Règle des Boy Scouts (The Boy Scout Rule)

> Il faut laisser le code dans un meilleur état que celui dans lequel on l’a trouvé

• L’essentiel n’est pas le refactoring massif, mais l’amélioration continue et progressive
• Corriger un nom de fonction confus, supprimer du code dupliqué, ajouter des tests manquants : il faut pratiquer de petites améliorations à chaque passage
• Robert C. Martin (Uncle Bob) l’a appliquée au développement logiciel dans Clean Code (2008)
• Principe des ingénieurs Google : "If you touch it, you own it" — si vous modifiez le code, vous prenez aussi la responsabilité de sa qualité
• Appliquer cette règle permet d’éviter l’effet vitre brisée (Broken Windows) et d’empêcher l’accumulation de dette technique

26. Loi de Murphy (Murphy's Law)

> Tout ce qui peut mal tourner tournera mal

• Base du defensive programming, de la gestion des exceptions et de la conception résiliente aux pannes
• En logiciel, il faut concevoir la gestion des erreurs et les mécanismes de repli en partant du principe que "toute erreur possible finira par se produire"

27. Loi de Postel / principe de robustesse (Postel's Law)

> Soyez conservateur dans ce que vous faites, libéral dans ce que vous acceptez des autres

• En conception d’API, le principe veut que les sorties respectent strictement la spécification, tandis que les entrées acceptent avec souplesse des formats variés
• Principe de robustesse établi par Jon Postel lors de la conception des protocoles TCP/IP
• Ligne directrice concrète pour améliorer l’interopérabilité entre systèmes

28. Théorie de la vitre brisée (Broken Windows Theory)

> Ne laissez pas perdurer une mauvaise conception, de mauvaises décisions ou du code de faible qualité

• Si l’on laisse un seul "carreau cassé" (du mauvais code) en place, cela entraîne une dégradation supplémentaire de la qualité
• Lorsque des commentaires TODO, du code mort et des avertissements non résolus s’accumulent dans une codebase, le nouveau code tend lui aussi à être écrit à un niveau inférieur
• Il est important d’instaurer une culture où même les petits problèmes sont corrigés dès qu’ils sont détectés

29. Dette technique (Technical Debt)

> Tout élément qui ralentit la vitesse de développement logiciel

• Ward Cunningham a utilisé pour la première fois cette métaphore financière à OOPSLA en 1992 : prendre des raccourcis dans le code revient à emprunter du temps sur l’avenir
• Principal (coût de correction) + intérêts (baisse continue de productivité due à un code désordonné)
• La dette technique intentionnelle peut parfois être rationnelle (timing de mise sur le marché, prototypage), mais un plan de remboursement est indispensable
• Exemple typique : faire l’impasse sur les tests automatisés ; la release se passe bien, mais chaque changement ultérieur fait apparaître des bugs inattendus
• Solutions : refactoring, ajout des tests manquants, amélioration de la conception

30. Loi de Linus (Linus's Law)

> Avec un nombre suffisant de relecteurs, tous les bugs deviennent faciles à trouver

• Principe central du développement open source : avec suffisamment de regards, les bugs deviennent des problèmes mineurs
• Expression nommée par Eric Raymond dans The Cathedral and the Bazaar en référence à Linus Torvalds
• Souligne l’importance de la culture du code review

31. Loi de Kernighan (Kernighan's Law)

> Déboguer est deux fois plus difficile qu’écrire le code au départ

• Par conséquent, si vous écrivez du code aussi astucieusement que possible, vous ne serez plus assez astucieux pour le déboguer
• Pourquoi il faut écrire un code simple et très lisible
• Présenté par Brian Kernighan dans The Elements of Programming Style

32. Pyramide de tests (Testing Pyramid)

> Un projet doit avoir beaucoup de tests unitaires rapides, moins de tests d’intégration et seulement un petit nombre de tests UI

• Tests unitaires (base) : rapides, peu coûteux, et les plus nombreux
• Tests d’intégration (milieu) : valident les interactions entre composants
• Tests UI/E2E (sommet) : lents et fragiles, donc à minimiser
• Modèle de stratégie de test présenté par Mike Cohn dans Succeeding with Agile

33. Paradoxe du pesticide (Pesticide Paradox)

> Si l’on exécute les mêmes tests de façon répétée, leur efficacité diminue avec le temps

• Les bugs que les tests existants pouvaient déjà détecter ont tous été trouvés ; il faut donc continuer à ajouter de nouveaux cas de test
• Il est indispensable de revoir et de mettre à jour régulièrement le jeu de tests

34. Lois de Lehman sur l’évolution des logiciels (Lehman’s Laws of Software Evolution)

> Les logiciels qui reflètent le monde réel doivent nécessairement évoluer, et cette évolution comporte des limites prévisibles

• Les logiciels de type E (qui reflètent le monde réel) doivent inévitablement être modifiés en continu pour rester utilisables
• À chaque changement, la complexité augmente et, sans gestion active, la qualité se dégrade

35. Loi de Sturgeon (Sturgeon’s Law)

> 90 % de tout est sans valeur

• Proposée par Theodore Sturgeon en réponse aux critiques de la littérature de science-fiction
• S’applique aussi au logiciel : parmi la plupart des codes, outils et frameworks, très peu sont réellement excellents
• Il faut maintenir des standards de qualité élevés et se concentrer sur les 10 % qui ont de la valeur

---

Scale

36. Loi d’Amdahl (Amdahl’s Law)

> Le gain de vitesse apporté par la parallélisation est limité par la part de travail qui ne peut pas être parallélisée

• Si 5 % d’un programme est séquentiel, alors même en ajoutant un très grand nombre de processeurs, le gain de vitesse théorique maximal est de 20x
• Il est plus efficace de reconnaître les limites de la parallélisation et de réduire les goulots d’étranglement séquentiels
• Formulée par Gene Amdahl en 1967

37. Loi de Gustafson (Gustafson’s Law)

> On peut obtenir un gain de vitesse important en calcul parallèle en augmentant la taille du problème

• Perspective complémentaire à la loi d’Amdahl : pour des problèmes extensibles plutôt que fixes, ajouter des processeurs est efficace
• En traitement du big data, simulation scientifique, etc., davantage de ressources permettent de résoudre des problèmes plus vastes

38. Loi de Metcalfe (Metcalfe’s Law)

> La valeur d’un réseau est proportionnelle au carré du nombre de ses utilisateurs

• Avec 10 utilisateurs, la valeur atteint 100 unités ; avec 100 utilisateurs, 10 000 unités
• Base théorique des effets de réseau dans les réseaux sociaux, messageries, marketplaces, etc.
• Proposée par Robert Metcalfe pour expliquer la valeur de la technologie Ethernet

---

Conception

39. Principe DRY (Don’t Repeat Yourself)

> Toute connaissance doit avoir une représentation unique, claire et faisant autorité

• Cela inclut non seulement la duplication de code, mais aussi la duplication de connaissances, de logique et de données
• La duplication oblige à modifier plusieurs endroits à la fois, ce qui devient une source de bugs et d’incohérences
• Formellement défini par Andy Hunt et Dave Thomas dans The Pragmatic Programmer

40. Principe KISS (Keep It Simple, Stupid)

> La conception et les systèmes doivent être aussi simples que possible

• La complexité augmente les coûts de compréhension, de maintenance et de débogage
• Une solution simple est dans la plupart des cas plus efficace et moins sujette aux défauts
• Issu d’un principe de conception proposé par l’US Navy dans les années 1960

41. Principes SOLID (SOLID Principles)

> Cinq lignes directrices fondamentales pour améliorer la conception logicielle

• S — principe de responsabilité unique (Single Responsibility) : une classe ne doit changer que pour une seule raison
• O — principe ouvert/fermé (Open-Closed) : ouvert à l’extension, fermé à la modification
• L — principe de substitution de Liskov : un sous-type doit pouvoir remplacer un type parent
• I — principe de ségrégation des interfaces : un client ne doit pas dépendre d’interfaces qu’il n’utilise pas
• D — principe d’inversion des dépendances : les modules de haut niveau ne doivent pas dépendre des modules de bas niveau, mais des abstractions
• Formalisés par Robert C. Martin ; l’acronyme SOLID a été nommé par Michael Feathers

42. Loi de Déméter (Law of Demeter)

> Un objet ne doit interagir qu’avec ses amis directs et éviter la communication directe avec des objets étrangers

• Principe selon lequel il faut éviter les appels chaînés comme a.getB().getC().doSomething()
• Réduit le couplage et renforce l’encapsulation, ce qui limite l’impact des changements
• Aussi appelée « principe de moindre connaissance »

43. Principe de moindre surprise (Principle of Least Astonishment)

> Les logiciels et les interfaces doivent fonctionner de la manière la moins surprenante possible pour les utilisateurs et les autres développeurs

• Les fonctions, API et UI doivent avoir un comportement prévisible dans leur nommage et leurs conventions
• Si une fonction delete() archive en réalité au lieu de supprimer, cela crée une surprise → défaut de conception
• Un comportement non intuitif entraîne des bugs et des erreurs utilisateur

44. YAGNI (You Aren’t Gonna Need It)

> N’ajoutez pas de fonctionnalité avant qu’elle soit nécessaire

• Principe central de l’Extreme Programming (XP), proposé par Ron Jeffries à la fin des années 1990
• Écrire du code sous prétexte qu’« on pourrait en avoir besoin plus tard » entraîne de la surconception et une charge de maintenance supplémentaire
• Pour appliquer YAGNI, il faut avoir confiance dans le refactoring (bonne couverture de tests, CI)
• Si seul l’export JSON est nécessaire aujourd’hui, implémentez uniquement JSON ; ajoutez XML/YAML, etc., lorsqu’ils seront demandés

---

Prise de décision

45. Effet Dunning-Kruger (Dunning-Kruger Effect)

> Moins on en sait sur un sujet, plus on a tendance à être confiant

• Phénomène où un développeur débutant sous-estime la difficulté d’un système complexe, tandis qu’un expert fait au contraire preuve de plus d’humilité vis-à-vis de ses connaissances
• Il est important d’améliorer la justesse de la conscience de soi par la revue de code, le mentorat et l’apprentissage continu

46. Rasoir de Hanlon (Hanlon’s Razor)

> N’attribuez pas à la malveillance ce qui s’explique suffisamment par la bêtise ou la négligence

• Avant d’interpréter le mauvais code ou les mauvaises décisions d’un collègue comme du sabotage intentionnel, il faut d’abord envisager l’ignorance, l’erreur ou le manque de temps
• Base de la confiance et d’une communication constructive dans l’équipe

47. Rasoir d’Occam (Occam’s Razor)

> L’explication la plus simple est souvent la plus juste

• En débogage, vérifiez d’abord la possibilité la plus simple avant de chercher des causes complexes
• En architecture aussi, il faut explorer d’abord une solution simple avant d’ajouter des couches d’abstraction inutiles

48. Biais des coûts irrécupérables (Sunk Cost Fallacy)

> Tendance à maintenir un choix perdant uniquement parce qu’on y a déjà investi du temps ou de l’énergie

• Mécanisme psychologique qui fait qu’on n’arrive pas à abandonner une fonctionnalité développée pendant 6 mois, même si elle allait dans la mauvaise direction, à cause du temps déjà investi
• Une bonne décision doit se fonder non sur l’investissement passé, mais sur la valeur future

49. La carte n’est pas le territoire (The Map Is Not the Territory)

> Une représentation de la réalité (un modèle) n’est pas la réalité elle-même

• Les diagrammes UML, documents d’architecture, modèles de données, etc. ne sont que des approximations du réel
• Il ne faut pas accorder une confiance aveugle au modèle ; il faut observer le comportement réel du système et mettre le modèle à jour

50. Biais de confirmation (Confirmation Bias)

> Tendance à privilégier les informations qui confirment une croyance ou une idée préexistante

• Piège consistant à ne collecter de manière sélective que les informations favorables à la stack technique ou aux choix de conception que l’on a retenus
• La clé d’une prise de décision équilibrée est de rechercher activement les preuves contraires et d’accepter des points de vue variés

51. Le Hype Cycle et la loi d'Amara (The Hype Cycle & Amara's Law)

On a tendance à surestimer les effets à court terme d'une technologie et à sous-estimer son impact à long terme

• Le Hype Cycle de Gartner : déclencheur technologique → pic des attentes exagérées → vallée de la désillusion → pente de l'illumination → plateau de productivité
• Lorsqu'on adopte une nouvelle technologie (blockchain, IA, etc.), il faut éviter de se laisser emporter par la surchauffe à court terme et évaluer sa pertinence pratique à long terme

52. L'effet Lindy (The Lindy Effect)

Plus une chose est utilisée depuis longtemps, plus elle a de chances de continuer à être utilisée à l'avenir

• Les technologies utilisées depuis des décennies, comme UNIX, SQL ou le langage C, ont de fortes chances de continuer à survivre longtemps
• Une base théorique pour choisir une technologie éprouvée plutôt qu'un nouveau framework
• Popularisé par Nassim Nicholas Taleb dans Antifragile

53. La pensée par premiers principes (First Principles Thinking)

Une méthode de pensée qui consiste à décomposer un problème complexe en ses composants les plus fondamentaux, puis à le reconstruire à partir d'eux

• Éliminer les pratiques et hypothèses existantes pour partir des vérités fondamentales et en déduire une solution
• Célèbre pour son application par Elon Musk à la réduction des coûts des fusées de SpaceX
• Lors de la conception de systèmes complexes, il faut se méfier du raisonnement du type « on a toujours fait comme ça »

54. Le raisonnement par inversion (Inversion)

Une méthode qui consiste à supposer le résultat inverse et à raisonner à rebours pour résoudre un problème

• Au lieu de se demander « comment réussir », commencer par « comment échouer » pour identifier les facteurs de risque
• Base théorique de l'analyse des modes de défaillance (Failure Mode Analysis) et du pre-mortem
• Un modèle mental souvent utilisé par Charlie Munger

55. Le principe de Pareto / la règle des 80/20 (Pareto Principle)

80 % des problèmes proviennent de 20 % des causes

• 80 % des bugs ont tendance à se concentrer dans 20 % du code
• Concentrer les ressources sur les 20 % les plus impactants est une stratégie efficace d'allocation des ressources
• Dérivé du principe observé par Vilfredo Pareto dans la répartition de la propriété foncière en Italie

56. La loi de Cunningham (Cunningham's Law)

La meilleure façon d'obtenir une réponse correcte sur Internet n'est pas de poser une question, mais de publier une mauvaise réponse

• Les gens participent plus volontiers à la correction d'informations erronées qu'à la réponse à une question
• Cette loi porte le nom de Ward Cunningham (inventeur du wiki), mais c'est en réalité Steven McGeady qui lui a donné ce nom
• Un enseignement utile pour la documentation et le partage de connaissances dans les communautés open source