La loi de Murphy est très connue dans le milieu informatique....
Vous allez sûrement être d'accord avec tous ceux qui l'ont déjà subi...
http://www.rigoler.com vous propose une version plus complète, ainsi que certains sites web dédiés à cette fameuse loi!!
La loi de MURPHY, ou le comportement des objets inanimés.
C'est la loi de la tartine beurrée ou encore celle de l'emmerdement maximum (ou LEM). La loi de Murphy régit le comportement des objets inanimés. L'homme qui a développé ce concept est Edsel Murphy; il est pratiquement inconnu de la plupart des ingénieurs et techniciens. Il est en fait victime de sa propre loi!
La loi fondamentale de Murphy, qui a donné de très nombreux corollaires dans les domaines les plus divers, s'énonce ainsi : "Si quelque chose peut aller de travers, le phénomène se produira, en particulier au cours d'une démonstration".
En voici quelques exemples :
En général
==========
* Tout ce qui est susceptible de mal tourner tournera nécessairement mal.
* Rien n'est aussi simple qu'il y paraît.
* Tout prend plus de temps que ce que vous aviez prévu.
* Si plusieurs choses sont susceptibles de mal tourner, celle qui tournera mal est celle qui causera le plus de dégâts. Corollaire: S'il y a un moment où il ne faut surtout pas que quelque chose aille mal, c'est à ce moment que ça arrivera.
* Si quelque chose ne peut en aucun cas mal tourner, ça le fera quand même.
* Si vous avez trouvé quatre façons possibles pour que les choses tournent mal, et que vous les avez circonvenues, alors une cinquième façon, que vous n'aviez pas prévue, apparaîtra spontanément.
* Laissées à elles-mêmes, les choses ont tendance à aller de mal en pis.
* Si tout semble bien se passer, c'est que vous n'avez manifestement pas remarqué quelque chose.
* L'Univers n'est pas indifférent à l'intelligence, il lui est activement hostile.
* Chaque solution apporte de nouveaux problèmes.
Dans l'Informatique
===================
Les erreurs indétectables sont en nombre infini, contrairement aux erreurs détectables dont le nombre catalogué est très limité.
Si on ajoute un homme à un projet en retard, cela ne fera qu'ajouter du retard.
Faire disparaître un message d'erreur est une utopie : vous n'avez simplement pas encore trouvé celui qui l'a remplacé.
La fonction annuler n'est jamais disponible quand vous en auriez besoin.
Ce n'est qu'après avoir essayé tout le reste, qu'on lit la documentation. C'est à ce moment qu'on se rend compte qu'on l'a jetée avec l'emballage.
Tout programme non trivial contient au moins un bug. Aucun programme n'est trivial.
Dès que vous quittez l'imprimante des yeux, elle a un problème.
C'est généralement lorsque le disque dur plante qu'on se rend compte qu'on a oublié de le sauvegarder. Sinon, c'est en le sauvegardant qu'on l'a fait planter.
Deuxième loi, de Weinberg:
Si les constructeurs construisaient les bâtiments de la manière dont les programmeurs écrivent les programmes, le premier pic-vert qui passerait détruirait la civilisation.
Loi commune de la bureautique et de la programmation réunies :
1.) Si le document est censé exister, il n'existe pas.
2.) Si le document existe, il est périmé.
3.) Seule la documentation pour les programmes inutiles transgresse les deux premières lois.
Pour savoir combien de temps ça prend pour écrire et débugger un programme, faites votre estimation la plus fiable, ajoutez un, multipliez par deux, et arrondissez à la dizaine supérieure.
Lois de l'écriture de programmes pour ordinateurs
Première loi
Tout programme, quel qu'il soit, dès qu'il est commercialisé est obsolète.
Deuxième loi
Tout nouveau programme coûte plus cher et est plus lent à faire tourner que l'ancien.
Troisième loi
Si un programme est très utile, il devra être changé par un autre.
Quatrième loi
Si un programme est inutile, il faudra lui faire une documentation.
Cinquième loi
Tout programme lors de son lancement aura tendance à remplir toute la RAM disponible
Sixième loi
La valeur d'un programme est inversement proportionnelle à la taille des documents qu'il génère.
Septième loi
La complexité d'un programme s'accroît jusqu'à ce qu'elle dépasse les capacités du programmeur qui en assure le développement.
Troisième loi de Greer:
Un programme informatique fait ce que vous lui dites de faire, pas ce que vous voudriez qu'il fasse.
Premier postulat de Troutman:
Les jurons sont les seules expressions comprises par tous les programmeurs.
Deuxième postulat de Troutman:
Ce n'est que lorsqu'un programme sera commercialisé depuis 6 mois que les plus graves erreurs seront détectées.
Troisième postulat de Troutman:
Les cartes de contrôle de travail qui doivent être classées dans un ordre précis seront classées dans le désordre.
Quatrième postulat de Troutman:
Des cassettes supposées être interchangeables ne le seront pas.
Cinquième postulat de Troutman:
Si le programme a été étudié pour rejeter toute entrée erronée, le premier crétin ingénieux trouvera un moyen de faire accepter de mauvaises valeurs par le programme.
Sixième postulat de Troutman:
Si une installation test fonctionne parfaitement, tous les systèmes qui en dépendent vont planter.
La zone de danger pour un ordinateur dépend de la longueur de son cordon d'alimentation.
Une des raisons qui expliquent que les ordinateurs accomplissent plus de travail que les humains , c'est que eux n'ont pas à s'arrêter pour répondre au téléphone.
Si les ordinateurs deviennent trop puissants, on peut toujours les organiser en comités.
À la source de chaque erreur imputée à l'ordinateur, on découvrira au moins 2 erreurs humaines (on compte ici l'erreur qui consiste à imputer la faute à l'ordinateur).
Si on met n'importe quoi dans un ordinateur, la seule chose qu'on peut en tirer, c'est n'importe quoi. Mais ce 'n'importe quoi', en étant passé par une machine coûtant très cher, est comme qui dirait 'anobli', et personne n'ose le critiquer.
Loi de Pierce:
Lors de chaque test de programme sur un nouveau système, la machine va toujours mal interpréter, mal afficher, mal imprimer, ou encore n'évaluera pas des sous-routines mathématiques, et tout ça dès le premier test.
Corollaire de la loi de Pierce:
Quand un compilateur accepte un programme sans erreur lors de la première exécution, le programme ne fournira pas les données que l'on attend de lui.
Première loi de Golub de la domination informatique:
Des objectifs de projet flous sont pratiques pour éviter l'embarras d'une estimation des coûts correspondants.
Deuxième loi de Golub de la domination informatique:
Un projet préparé sans soin prendra trois fois plus de temps que prévu pour son achèvement; un projet préparé soigneusement prendra seulement deux fois le temps prévu.
Troisième loi de Golub de la domination informatique:
L'effort à fournir pour corriger le cap d'un projet s'accroît géométriquement avec le temps.
Quatrième loi de Golub de la domination informatique:
Les équipes de projets de développement détestent les briefings hebdomadaires sur l'avancement du projet. Ils mettent en évidence que le projet n'avance pas.
Première loi de Gilb sur la confiance:
On ne peut pas compter sur les ordinateurs, mais encore moins sur les humains.
Les ordinateurs ne sont pas intelligents. Mais ils pensent qu'ils le sont.
Les vieux programmeurs ne meurent pas. Ils se branchent simplement à une autre adresse.
Dans les démonstrations
=======================
Toute démonstration qui fonctionnait de façon impeccable pendant les répétitions, foirera lamentablement au cours de la démonstration publique.
Lois de Golub du management
Lois publiées par M. Golub dans DATA MANAGEMENT, en 1974.
LOI N° 1 : Aucun grand projet informatique n'est jamais mis en place dans les délais, dans les limites du budget, avec le même personnel qu'au départ, et le projet ne fait pas ce qu'il est censé faire non plus. Il est fort improbable que le nôtre soit le premier.
LOI N° 2 : L'un des avantages de fixer des objectifs vagues à un projet, c'est que vous n'aurez pas de difficultés à estimer les dépenses correspondantes.
LOI N° 3 : L'effort nécessaire à redresser le cap croît géométriquement avec le temps.
LOI N° 4 : Les buts, tels que les entend celui qui en décide, seront compris différemment par chacun des autres.
LOI N° 5 : Seuls les bénéfices mesurables sont réels. Or les bénéfices immatériels ne sont pas mesurables. Donc les bénéfices immatériels ne sont pas réels.
LOI N° 6 : Toute personne qui peut travailler à temps partiel pour un projet n'a sûrement pas assez de travail en ce moment.
LOI N° 7 : Plus grande est la complexité d'un projet, moins vous avez besoin d'un technicien pour le diriger: trouvez le meilleur manager possible, lui trouvera le technicien.
LOI N° 8 : Un projet mal planifié prendra trois fois plus de temps. Un projet bien planifié prendra seulement deux fois plus de temps.
LOI N° 9 : S'il y a un risque que quelque chose marche mal, ça marchera mal.
LOI N° 10 : Quand les choses vont bien, quelque chose ira mal. Quand les choses semblent aller mieux, c'est que vous oubliez quelque chose.
LOI N° 11 : Les équipes de projet détestent les comptes-rendus hebdomadaires d'avancement des travaux parce que ceux-ci mettent trop vivement en lumière l'absence de leur progrès.
LOI N° 12 : Les projets progressent rapidement jusqu'à 90%, puis ils restent achevés à 90% pour toujours.
LOI N° 13 : Si on laisse le contenu d'un projet changer librement, le taux de changement dépassera le taux d'avancement.
LOI N° 14 : Si un utilisateur ne croit pas au système, il créera un système parallèle. Ni l'un ni l'autre ne fonctionneront très bien....