Trolldi : les célèbres lois de l'informatique et du développement logiciel
Quelles sont celles qui impactent votre travail le plus souvent ?
Le 2019-02-27 13:19:24, par Michael Guilloux, Chroniqueur Actualités
Comme dans tout autre domaine, le monde du développement logiciel comporte des règles, principes et lois que les développeurs et autres professionnels de l'informatique ont souvent tendance à citer dans leurs discussions ou observer dans leur travail quotidien. Ces lois, règles ou principes sont énoncés expressément par des célébrités du monde ou tirés des livres et déclarations de ces dernières et reconnus en tant que tels par la communauté IT. Ci-dessous, une liste de lois, règles et principes du monde IT, avec dans certains cas, des interprétations dont elles font l'objet.
La loi de Murphy
La loi de Murphy est un adage énonçant que « tout ce qui est susceptible de mal tourner tournera mal ». Selon une variante plus détaillée de la loi : « S'il existe au moins deux façons de faire quelque chose et qu'au moins l'une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu'un quelque part pour emprunter cette voie. »
On peut interpréter la loi de Murphy comme une règle de conception : on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout système comme si la loi était vraie. En particulier, un équipement doit être à l'épreuve non seulement des accidents les plus improbables, mais aussi des manœuvres les plus stupides de la part de l'utilisateur. Elle justifie donc les principes de la conception défensive préconisant de planifier et d'éliminer d'emblée les possibilités de mauvaise utilisation.
La loi de Brooks
La loi de Brooks — d'après Frederick Brooks — est une prédiction sur la productivité des projets informatiques : « Ajouter des personnes à un projet en retard accroît son retard ». Le postulat est que la plupart des tâches ne sont pas partitionnables et que les nouveaux arrivants vont faire perdre du temps aux équipes en place en temps de communication. Ce temps perdu étant proportionnel à n(n-1) (où n est le nombre de personnes impliquées). Le paramètre taille d'une équipe influe comme une loi de rendement décroissant dans la productivité en informatique. Une analogie culinaire est qu'en étant 300 dans une cuisine pour faire un œuf au plat il ne sera pas possible de servir le plat 300 fois plus vite.
La loi de Hofstadter
La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de la planification dans le domaine de la recherche et du développement. Elle est régulièrement constatée dans le domaine du développement de logiciel. Elle affirme : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. »
Derrière une telle formulation, la loi de Hofstadter rend compte d'une difficulté universelle : il est presque impossible de prévoir le temps qui sera nécessaire à l'accomplissement d'une tâche complexe. Cette impossibilité est mise en exergue par le caractère auto-référentiel de la phrase qui se cite elle-même : de ce fait, elle introduit un « raisonnement en boucle ».
La loi de Conway
La loi de Conway est un adage attribué à Melvin Conway qui stipule que « les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. » Elle s'appuie sur le fait que pour fonctionner, un composant logiciel qui a de multiples auteurs nécessite à ceux-ci de communiquer fréquemment. C'est ainsi que la structure des interfaces logicielles d'un système sera le reflet des limites sociales de l'organisation qui l'a produite, au travers desquelles la communication est plus difficile.
Une variante de la loi de Conway, proposée par Eric Raymond, un militant de l'open source qui a cofondé l'Open Source Initiative, est que « si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes ».
Loi de Postel ou principe de robustesse
« Soyez tolérant [libéral] dans ce que vous acceptez, et pointilleux [conservateur] dans ce que vous envoyez ». Ce principe, attribué à John Postel, est l'un des principes fondateurs de l'approche qui sous-tend le protocole TCP, et se veut une proposition pour augmenter la résilience et la robustesse du code.
Loi de Pareto
La loi de Pareto, ou encore loi des 80-20, est un phénomène empirique constaté dans certains domaines : environ 80 % des effets sont le produit de 20 % des causes. C'est le principe derrière la douloureuse vérité que 80 % des bogues proviennent de 20 % du code. Une autre application de cette loi est que 80 % du travail réalisé dans une entreprise est effectué par 20 % du personnel. Le problème est qu'on n’a pas toujours une idée précise de quel 20 % il s'agit.
Principe de Peter
Le principe de Peter est une loi empirique relative aux organisations hiérarchiques. Selon ce principe, « dans une hiérarchie, tout employé a tendance à s'élever à son niveau d'incompétence », avec pour corollaire : « avec le temps, tout poste sera occupé par un employé incapable d'en assumer la responsabilité ». Autrement dit, le principe stipule que la promotion à un poste est basée sur la performance du candidat dans son rôle précédent plutôt que dans le rôle qu'il va occuper.
Principe de Kerckhoffs
Le principe de Kerckhoffs stipule qu'en cryptographie, « un système doit être sécurisé même si tout ce qui le concerne, à l'exception d'un petit élément d'information - la clé - est connu par le public. » Autrement dit, la sécurité d'un cryptosystème ne doit reposer que sur le secret de la clé.
La loi de Linus
En informatique, la loi de Linus, nommée en l'honneur de Linus Torvalds, et formulée par Eric Raymond, concerne le développement de logiciel. La loi indique qu’« avec suffisamment d'yeux, tous les bugs sont superficiels » ; ou plus formellement : « avec un groupe de bêta-testeurs et de co-développeurs suffisamment large, presque tous les problèmes seront rapidement analysés et le correctif sera évident pour l'un d'entre eux ». Présenter le code à une multitude de développeurs avec l'objectif d'avoir un consensus sur son acceptation est une forme simple de la revue de logiciel. La loi de Linus fait généralement partie de la philosophie de base des adeptes du mouvement open source et du logiciel libre.
Loi de Moore
Dans sa version la plus populaire, la loi de Moore stipule que le nombre de transistors dans les microprocesseurs double tous les deux ans. Mais il existe des pseudo lois de Moore, variables et sans lien avec les énoncés réels de Moore, qui sont largement diffusées comme celle selon laquelle la puissance des ordinateurs va doubler tous les deux ans.
Loi de Wirth
La loi de Wirth est une loi empirique qui stipule que « les programmes ralentissent plus vite que le matériel accélère ». Ou bien : le nombre d'instructions nécessaires à l'interprétation de programmes plus sophistiqués demande des ordinateurs plus rapides.
Autrement dit, alors que le matériel devient de plus en plus rapide, les programmes n'accélèrent pas pour autant. Au contraire, ils deviennent de plus en plus gros et lents, les développeurs justifiant cette lenteur excessive comme compensée par la loi de Moore. La loi de Moore devient ainsi une excuse à la production de bloatware. Les logiciels ont une lenteur ressentie constante bien que la puissance processeur de leur matériel augmente.
Le principe du 90-90
Le principe stipule que « le développement des premiers 90 % du code représentent 90 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement. » Cela fait donc 180 % du temps de développement. Ce principe cherche à mettre en évidence le fait que les projets logiciels ont en général tendance à dépasser largement le temps de développement prévu. Ce principe non seulement exprime l'allocation approximative de temps aux parties faciles et difficiles d'un projet de programmation, mais aussi explique le retard de nombreux projets par l'incapacité d'anticiper les parties difficiles. En d’autres termes, la réalisation d’un projet nécessite toujours plus de temps et plus de codage que prévu.
Le principe d'optimisation de Knuth
Le principe formulé par Donald Knuth stipule que « l'optimisation prématurée est la source de tous les maux. » Ce principe est considéré comme la règle numéro un de l'optimisation : l'optimisation ne doit intervenir qu'une fois que le programme fonctionne et répond aux spécifications fonctionnelles. L'expérience montre qu'appliquer des optimisations de bas niveau du code avant que ces deux conditions ne soient réalisées revient le plus souvent à une perte de temps et s'avère néfaste à la clarté du code et au bon fonctionnement du programme. Cependant cette citation, tronquée, est très souvent mal interprétée. On propose donc une version complète du principe d'optimisation de Knuth : « On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux. »
Loi de Norvig
En juillet 1999, un article de presse indiquait que l'utilisation des PC avait encore doublé aux USA, atteignant 50 % des foyers américains. Les gens voyaient cela comme un signe supplémentaire de l'inévitable ascension des PC, mais Peter Norvig le voyait plutôt comme un avertissement indiquant que « le verre était à moitié vide » et a formulé ce qui suit, appelé loi de Norvig : « Toute technologie dépassant un taux de pénétration de 50 % ne doublera plus jamais (dans un nombre quelconque de mois) [son taux de pénétration, NDLR]. »
Source : Tim Sommer
Et vous ?
Voir aussi :
La loi de Murphy
La loi de Murphy est un adage énonçant que « tout ce qui est susceptible de mal tourner tournera mal ». Selon une variante plus détaillée de la loi : « S'il existe au moins deux façons de faire quelque chose et qu'au moins l'une de ces façons peut entraîner une catastrophe, il se trouvera forcément quelqu'un quelque part pour emprunter cette voie. »
On peut interpréter la loi de Murphy comme une règle de conception : on ne considère pas la loi de Murphy comme vraie, mais on conçoit tout système comme si la loi était vraie. En particulier, un équipement doit être à l'épreuve non seulement des accidents les plus improbables, mais aussi des manœuvres les plus stupides de la part de l'utilisateur. Elle justifie donc les principes de la conception défensive préconisant de planifier et d'éliminer d'emblée les possibilités de mauvaise utilisation.
La loi de Brooks
La loi de Brooks — d'après Frederick Brooks — est une prédiction sur la productivité des projets informatiques : « Ajouter des personnes à un projet en retard accroît son retard ». Le postulat est que la plupart des tâches ne sont pas partitionnables et que les nouveaux arrivants vont faire perdre du temps aux équipes en place en temps de communication. Ce temps perdu étant proportionnel à n(n-1) (où n est le nombre de personnes impliquées). Le paramètre taille d'une équipe influe comme une loi de rendement décroissant dans la productivité en informatique. Une analogie culinaire est qu'en étant 300 dans une cuisine pour faire un œuf au plat il ne sera pas possible de servir le plat 300 fois plus vite.
La loi de Hofstadter
La loi de Hofstadter (ou Loi de glissement de planning) est une loi empirique concernant la difficulté de la planification dans le domaine de la recherche et du développement. Elle est régulièrement constatée dans le domaine du développement de logiciel. Elle affirme : « Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter. »
Derrière une telle formulation, la loi de Hofstadter rend compte d'une difficulté universelle : il est presque impossible de prévoir le temps qui sera nécessaire à l'accomplissement d'une tâche complexe. Cette impossibilité est mise en exergue par le caractère auto-référentiel de la phrase qui se cite elle-même : de ce fait, elle introduit un « raisonnement en boucle ».
La loi de Conway
La loi de Conway est un adage attribué à Melvin Conway qui stipule que « les organisations qui définissent des systèmes ... sont contraintes de les produire sous des designs qui sont des copies de la structure de communication de leur organisation. » Elle s'appuie sur le fait que pour fonctionner, un composant logiciel qui a de multiples auteurs nécessite à ceux-ci de communiquer fréquemment. C'est ainsi que la structure des interfaces logicielles d'un système sera le reflet des limites sociales de l'organisation qui l'a produite, au travers desquelles la communication est plus difficile.
Une variante de la loi de Conway, proposée par Eric Raymond, un militant de l'open source qui a cofondé l'Open Source Initiative, est que « si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes ».
Loi de Postel ou principe de robustesse
« Soyez tolérant [libéral] dans ce que vous acceptez, et pointilleux [conservateur] dans ce que vous envoyez ». Ce principe, attribué à John Postel, est l'un des principes fondateurs de l'approche qui sous-tend le protocole TCP, et se veut une proposition pour augmenter la résilience et la robustesse du code.
Loi de Pareto
La loi de Pareto, ou encore loi des 80-20, est un phénomène empirique constaté dans certains domaines : environ 80 % des effets sont le produit de 20 % des causes. C'est le principe derrière la douloureuse vérité que 80 % des bogues proviennent de 20 % du code. Une autre application de cette loi est que 80 % du travail réalisé dans une entreprise est effectué par 20 % du personnel. Le problème est qu'on n’a pas toujours une idée précise de quel 20 % il s'agit.
Principe de Peter
Le principe de Peter est une loi empirique relative aux organisations hiérarchiques. Selon ce principe, « dans une hiérarchie, tout employé a tendance à s'élever à son niveau d'incompétence », avec pour corollaire : « avec le temps, tout poste sera occupé par un employé incapable d'en assumer la responsabilité ». Autrement dit, le principe stipule que la promotion à un poste est basée sur la performance du candidat dans son rôle précédent plutôt que dans le rôle qu'il va occuper.
Principe de Kerckhoffs
Le principe de Kerckhoffs stipule qu'en cryptographie, « un système doit être sécurisé même si tout ce qui le concerne, à l'exception d'un petit élément d'information - la clé - est connu par le public. » Autrement dit, la sécurité d'un cryptosystème ne doit reposer que sur le secret de la clé.
La loi de Linus
En informatique, la loi de Linus, nommée en l'honneur de Linus Torvalds, et formulée par Eric Raymond, concerne le développement de logiciel. La loi indique qu’« avec suffisamment d'yeux, tous les bugs sont superficiels » ; ou plus formellement : « avec un groupe de bêta-testeurs et de co-développeurs suffisamment large, presque tous les problèmes seront rapidement analysés et le correctif sera évident pour l'un d'entre eux ». Présenter le code à une multitude de développeurs avec l'objectif d'avoir un consensus sur son acceptation est une forme simple de la revue de logiciel. La loi de Linus fait généralement partie de la philosophie de base des adeptes du mouvement open source et du logiciel libre.
Loi de Moore
Dans sa version la plus populaire, la loi de Moore stipule que le nombre de transistors dans les microprocesseurs double tous les deux ans. Mais il existe des pseudo lois de Moore, variables et sans lien avec les énoncés réels de Moore, qui sont largement diffusées comme celle selon laquelle la puissance des ordinateurs va doubler tous les deux ans.
Loi de Wirth
La loi de Wirth est une loi empirique qui stipule que « les programmes ralentissent plus vite que le matériel accélère ». Ou bien : le nombre d'instructions nécessaires à l'interprétation de programmes plus sophistiqués demande des ordinateurs plus rapides.
Autrement dit, alors que le matériel devient de plus en plus rapide, les programmes n'accélèrent pas pour autant. Au contraire, ils deviennent de plus en plus gros et lents, les développeurs justifiant cette lenteur excessive comme compensée par la loi de Moore. La loi de Moore devient ainsi une excuse à la production de bloatware. Les logiciels ont une lenteur ressentie constante bien que la puissance processeur de leur matériel augmente.
Le principe du 90-90
Le principe stipule que « le développement des premiers 90 % du code représentent 90 % du temps de développement. Les 10 % restants prennent 90 % du temps de développement. » Cela fait donc 180 % du temps de développement. Ce principe cherche à mettre en évidence le fait que les projets logiciels ont en général tendance à dépasser largement le temps de développement prévu. Ce principe non seulement exprime l'allocation approximative de temps aux parties faciles et difficiles d'un projet de programmation, mais aussi explique le retard de nombreux projets par l'incapacité d'anticiper les parties difficiles. En d’autres termes, la réalisation d’un projet nécessite toujours plus de temps et plus de codage que prévu.
Le principe d'optimisation de Knuth
Le principe formulé par Donald Knuth stipule que « l'optimisation prématurée est la source de tous les maux. » Ce principe est considéré comme la règle numéro un de l'optimisation : l'optimisation ne doit intervenir qu'une fois que le programme fonctionne et répond aux spécifications fonctionnelles. L'expérience montre qu'appliquer des optimisations de bas niveau du code avant que ces deux conditions ne soient réalisées revient le plus souvent à une perte de temps et s'avère néfaste à la clarté du code et au bon fonctionnement du programme. Cependant cette citation, tronquée, est très souvent mal interprétée. On propose donc une version complète du principe d'optimisation de Knuth : « On devrait oublier les petites optimisations locales, disons, 97 % du temps : l'optimisation prématurée est la source de tous les maux. »
Loi de Norvig
En juillet 1999, un article de presse indiquait que l'utilisation des PC avait encore doublé aux USA, atteignant 50 % des foyers américains. Les gens voyaient cela comme un signe supplémentaire de l'inévitable ascension des PC, mais Peter Norvig le voyait plutôt comme un avertissement indiquant que « le verre était à moitié vide » et a formulé ce qui suit, appelé loi de Norvig : « Toute technologie dépassant un taux de pénétration de 50 % ne doublera plus jamais (dans un nombre quelconque de mois) [son taux de pénétration, NDLR]. »
Source : Tim Sommer
Et vous ?
Voir aussi :
-
AoCannailleExpert confirméJ'ai un prof d'algo qui se basait énormément sur les travaix de knuth, et qui résumait sa pensée ainsi :
1. Make it work
2. Make it well
3. Make it fast.
En clair, l'objectif premier d'un programme est de fonctionner, sinon il n'a pas raison d'être.
Ensuite, il faut qu'il soit maintenable, sinon il n'a pas de raison de subsister
Enfin il peut être rapide. Mais s'il ne fonctionne pas, ou alors qu'il est déjà peu maintenable, aucune chance d'aboutir à quelque chose de potable.
ça tombe sous le sens. En pratique, avec ma petite expérience, on me laisse rarement le temps de bien finir l'étape "Make it well"...le 01/03/2019 à 11:25 -
CharvalosMembre éprouvéSinon, il y en a quelques-une que j'adore et qui ne sont pas citées :
Envoyé par Hanlon's razor Envoyé par Eagleson's Law le 01/03/2019 à 14:16 -
squizerMembre actifIl veut dire par là que la croissance ne peut que ralentir et à terme être nulle.le 01/03/2019 à 9:51
-
CaptainDangeaxMembre expérimentéLa loi de Wirth est trop vraie.
Un C64 mettait moins de 2 secondes entre l'appui sur le bouton power et la disponibilité du système près à recevoir des commandes au clavier. Aucune machine actuelle ne fait ça, quel que soit le noyau ou le shell.
Mon 486 avec une contrôlleur VLB + mémoire cache mettait moins de temps à démarrer Win3.1 qu'un bousin d'aujourd'hui à charger windows 10. Attention, par charger, je veux dire sans tâche de fond qui continue à mouliner le SSD ou le disque dur après l'affichage du shell.
Toutes les autres lois sont valides, à l'exception de la loi de Moore qui se heurte à la taille minimale (quantique) du transistor.le 01/03/2019 à 15:55 -
jvalloisMembre éprouvéApparemment, cette croix est toujours utilisée par la bundeswher qui, me semble-t-il, n'a plus rien à voir avec les nazis !le 01/03/2019 à 18:52
-
Uranne-jimmyMembre expérimentéIl ne faut pas confondre taux de pénétration et proportion de la population équipé.
Imaginez le taux de pénétration comme une accélération, multiplier par deux son accélération ne veut rien dire par rapport à la vitesse.
Pour le dire autrement, le taux de pénétration est l'augmentation de la proportion de la population équipé en fonction du temps.le 01/03/2019 à 11:01 -
10_GOTO_10Membre expérimentéMes chefs ont trouvé la parade depuis longtemps : il demandent au métier la date de dead-line. Ensuite, il faut deux mois de tests fonctionnels ? ils enlèvent deux mois. Il faut un mois de tests unitaires ? ils enlèvent un mois. Deux mois de débuggage et de mise au point ? Ils enlèvent encore deux mois. Ce qui reste, c'est pour le développement. Le développeur, c'est moi.le 01/03/2019 à 13:38
-
CincinnatusMembre expérimentéSoit t = taux de pénétration d'une technologie, cette loi dit donc que lorsque t dépasse 50%, il ne peut plus doubler.
Autrement dit, si t1 = 0.500000000000001, t ne peut atteindre 2 fois t1, soit 1.000000000000002, par exemple, soit plus de 100%.
En clair, un taux de pénétration ne peut dépasser 100%. Ce ne serait pas une évidence ?le 01/03/2019 à 8:58 -
AlvatenMembre éprouvéC'est sur que parfois ca peut très bien se passer. Le problème pour moi c'est qu'il y a une certaine pression social, on entend trop souvent "quoi à 35ans tu est encore dev, tu devrai être chef d'équipe au minium ?". Pour moi il n'y a pas de honte a dire qu'on est bien là ou on est.
Au lieu de changer de poste on devrait juste augmenter les salaires...
Mais après je pense que c'est parfois jouable qu'un développeur devienne chef de projet (selon ce qu'on entend par "chef de projet".
Selon la méthode, le chef de projet est un des développeurs de l'équipe qui a des responsabilités en plus.Ah ca c'est un autre problème aussi très vrai, et pas que dans l'informatique ! De mon expérience c'est jamais très bon d'avoir un chef qui commande un truc dont il ne comprend pas le fonctionnement.
Parfois il y a des chefs de projets qui n'ont jamais été développeur, c'est un peu dommage.le 01/03/2019 à 14:00 -
AlvatenMembre éprouvéNon la Croix de Malte est un peu différente (https://fr.wikipedia.org/wiki/Croix_...alte_(symbole))C'est pas une croix maltaise, ou de templier stylisé en noir ?
Qu'a-t-elle donc de dérangeant ?
Ici on est clairement par la forme et la couleur une Croix de Fer, la décoration allemande. J'imagine que le coté dérangeant vient du fait qu'on l'associe forcément aux nazies, même si elle existe en réalité depuis le 19ème. Après je vois ca plus comme de la provocation, même si personnellement ca me viendrai pas à l'idée de l'utiliser on la vois souvent chez les bikers ou les métaleux sans aucun rapport avec le III Reich.
Bon merci pour l'application d'une nouvelle loi "Plus une discussion en ligne dure longtemps, plus la probabilité d'y trouver une comparaison impliquant les nazis ou Adolf Hitler s’approche de 1" (Loi de Godwin) ca me permet de pas être trop hors-sujetle 01/03/2019 à 18:33