Les lois qui s'appliquent à vos projets informatiques
En tant que développeurs nous avons a lutter contre beaucoup de problèmes à toutes les étapes des projets que nous développons.
Mais savez-vous que la plupart d’entre eux peuvent se caser dans des lois et principes bien établis ?
En route pour découvrir que vos problèmes … sont communs à beaucoup de monde !
Loi de Golub
Un projet mal planifié prend trois fois plus de temps que prévu, alors que le même projet, bien planifié, n’aurait pris que deux fois le temps prévu
Plus de détails ici
Loi de Occam
L’explication la plus simple est celle qui a le plus de chance d’être correcte
Plus de détails ici
La loi de Murphy
Tout ce qui est susceptible de mal tourner tournera mal
Ou
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.
Ou
Si ce gars a la moindre possibilité de faire une erreur, il la fera
Ou
Si cela peut mal se passer, cela arrivera
Ou
S’il y a plus d’une façon de faire quelque chose, et que l’une d’elles conduit à un désastre, alors il y aura quelqu’un pour le faire de cette façon
Plus de détails sur Wikipedia
La loi de Brooks
Ajouter des personnes à un projet en retard accroît son retard
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
Plus de détails sur Wikipedia
La loi de Hofstadter
Il faut toujours plus de temps que prévu, même en tenant compte de la Loi de Hofstadter.
Plus de détails sur Wikipedia
La loi de Conway
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.
Ou
Si vous avez quatre équipes travaillant sur un compilateur, vous aurez un compilateur à quatre étapes
Ou
La structure d’un problème reflète la structure de l’organisation qui l’a créé
Plus de détails sur Wikipedia
Le principe de robustesse
Soyez conservateur dans ce que vous faites, soyez libéral dans ce que vous acceptez des autres
Ou
*Ne soyez pas un fasciste pyscho-rigide, essayez de comprendre votre interlocuteur au lieu d’insister qu’il a tort *
Plus de détails sur Wikipedia
Le principe de Pareto
Environ 80 % des effets sont le produit de 20 % des causes
Ou au cours d’un projet
Les premiers 80% d’une tâche prennent 20% du temps. Les 20% restants prennent 80% du temps
Plus de détails sur Wikipedia
Le principe de Peter
Dans toute hiérarchie, toute personne a tendance à s’élever jusqu’à son niveau d’incompétence
Plus de détails sur Wikipedia
La loi de Linus
avec suffisamment d’yeux, tous les bugs sont superficiels
Ou
avec un groupe de beta-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
Plus de détails sur Wikipedia
La loi de Wirth
les programmes ralentissent plus vite que le matériel accélère
Ou
le nombre d’instructions nécessaires à l’interprétation de programmes plus sophistiqués demande des ordinateurs plus rapides
Plus de détails sur Wikipedia
Le principe de l’optimisation prématurée
Les programmeurs perdent énormément de temps à réfléchir à la vitesse des parties non critiques de leurs programmes ou à s’inquiéter de leur rapidité. Ces tentatives d’efficacité ont en réalité un impact très négatif sur le débogage et la maintenance. Nous devrions oublier les petites efficacités, disons environ 97% du temps: une optimisation prématurée est la racine de tout mal. Pourtant, nous ne devrions pas laisser passer nos opportunités dans ce 3% critique
Plus de détails ici
Cet article a été inspiré de l’article Anglophone de Tim Sommer (https://www.timsommer.be/famous-laws-of-software-development/)