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/)

Written on February 28, 2019