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 ?
Quelles sont les lois qui impactent votre travail le plus souvent ? Et comment ? Votre loi préférée a-t-elle été omise ? Si oui, de quelle loi s'agit-il ? Que dit-elle et comment vous impacte-elle ? Êtes-vous d'accord ou pas avec chaque loi énoncée ici ? Avez-vous une expérience (amusante) avec l'une d'entre elles ?Voir aussi :
Trolldi : toi aussi joue à Fortnite et gagne 10 millions de dollars en un an, une bonne façon de gagner sa vie ? Trolldi : après les emplois humains, les robots voudraient-ils prendre la place de nos animaux de compagnie ? Lovot souhaite vous rendre heureux Best of Trolldi : quels ont été vos trolldi préférés en 2018 ? Voici les 10 trolldi les plus lus de 2018 Trolldi : Google et l'ONU sont parmi les pires auteurs d'erreurs liées aux MdP en 2018, d'après les résultats d'une enquête Trolldi : comment certains auteurs et développeurs voient-ils les langages de programmation ? Petite compilation de citations dans l'industrie 
Envoyé par Michael Guilloux
.