[Mythologie du geek] Les lois du geek - part 2

Le premier article sur les lois du geek vous présentait les lois les plus connues. Voilà maintenant des lois  réservées à ceux qui ont déjà mis les mains dans le cambouis de la programmation (Java, C, C#, Assembleur, Fortran 75 ou même Basic). Vous pouvez tout de même les comprendre si Dilbert est votre livre de chevet (on parle beaucoup de gestion de projet informatique dans ces lois).
Elles sont toutes issues d’un très bon article en anglais :  Geek Laws ; mais dans mon ineffable gentillesse, je vous les ai traduit (rapidement, hey, vous moquez pas). Si vous avez de meilleures traductions à proposer, n’hésitez pas. Je vous ai également fait un petit dessin pour continuer à tester une vieille palette graphique qui traînait dans un placard (fait en 1h montre en main, tout à la palette, ça le fait non ?).

Les lois des info-geeks

Troisième loi du Manque de Fiabilité de Gilb
Les erreurs indétectables sont infinies, contrairement aux erreurs identifiables qui, par définition, sont limitées.

Second postulat de Programmation de Troutman
La vulgarité est le langage que les programmeurs connaissent le mieux.

Loi de Brook
Ajouter de la main-d’oeuvre à un projet en retard le retarde d’autant plus.

Loi de Brooke (avec un “e”)
Quand un système est complètement défini, il y a toujours un gars qui découvre quelque chose qui soit abolit le système ou le transforme jusqu’à ce qu’on ne le reconnaisse plus.

Première loi de Computerdom de Golub
Un projet planifié avec négligence prend trois fois plus de temps que prévu ; un projet planifié  soigneusement prend seulement deux fois plus longtemps.

Seconde loi de Wyszkowski
Tout peut marcher si vous jouez suffisamment avec.

Deuxième loi de la Procrastination
La procrastination réduit l’anxiété en diminuant la qualité attendue du projet, des meilleurs efforts possibles attendus aux meilleurs efforts possibles étant donné le temps limité.

Quatrième loi de procrastination
La procrastination peut supprimer entièrement le travail si son besoin passe avant que le travail soit fait.

Première loi de Brien
À un moment dans le cycle de vie d’une organisation, sa capacité à réussir en dépit de soi-même vient à manquer.

Huitième loi des Ingénieurs Naïfs
Les changements les plus importants dans la projet seront toujours demandés quand sa réalisation sera presque terminé.

Principe d’Inertie de la Conception
Tout changement semble terrible au premier abord.

Principe d’Eng
Plus c’est facile à faire, plus c’est difficile à changer.

Première loi de la Qualité de Wright
La qualité est inversement proportionnelle au temps laissé pour l’achèvement du projet.

Première loi de la Planification d’Entreprise
Tout ce qui peut être modifié le sera jusqu’à ce qu’il n’y ait plus le temps de changer quelque chose.

Loi de Leo
Plus c’(le bug)est difficile à trouver, plus c’est facile à corriger. Et vice-versa.

Seconde loi de Weinberg
Si les constructeurs de bâtiments construisait de la même façon que les programmeurs écrivent des programmes, le premier pic-vert venu pourrait détruire la civilisation.

Voilà donc les lois que les vrais développeurs expérimentés connaissent. Si vous en voyez d’autres, n’hésitez pas à les ajouter dans les commentaires ci-dessous.

Et n’oubliez jamais cette loi absolue pour ne pas vexer un développeur :

Un programmeur n’est pas, et ne sera jamais un programmateur !