Citations et lois de Murphy
Par Mathieu le jeudi 17 janvier 2008, 13:00 - Humour - Lien permanent
Ce billet est issu d'une sauvegarde de mon ancien blog, il est peut être obsolète, mais conserve un intérêt dans le contexte de ce blog.
It’s not a bug, it’s a
feature.
Un transistor PNP est en
général un NPN.
Il ne faut pas que les lois
de la physique dépendent de quel côté du laboratoire vous travaillez.
À plus que les
ordinateurs deviennent intelligents, à plus que c’est des emmerdeurs.
Tous les dix-huit mois, la
vitesse des logiciels est divisée par deux.
Avant
même de fonctionner, tout programme est déjà obsolète.
Une application
pleinement satisfaisante est toujours complétée par une mise à jour
buggée.
« Compatibilité ascendante »
signifie que toutes les erreurs de conception originelles sont
conservées.
Grâce à l’ordinateur, on
peut faire plus rapidement des choses qu’on n’aurait pas eu besoin de
faire sans ordinateur.
Rappelez-vous
que ce n’est pas un hasard si l’informatique et la théorie du chaos se
sont développées simultanément.
Ça marcherait mieux si vous
le branchiez (en dernier ressort basculer l’interrupteur).
C’est
après avoir pleuré des heures « putain pourquoi mes deux PCs ne se
voient pas ???? Finalement c’est de la daube Linux ! » que vous vous
rappelez que les deux machines ne sont pas connectées.
C’est
le jour où vous avez enlevé la batterie de votre portable pour la
décharger qu’une microcoupure surviendra et vous fera perdre 4 heures de
travail.
La taille
d’un document sauvegardé par un programme est proportionnel à
l’exponentielle du numéro de version dudit programme.
Exception :
Proportionnalité simple pour les produits non Micro$oft.
La légitimité d’une copie est
inversement proportionnelle à son intérêt.
Ça prend toujours plus
de temps de graver un CD pour les autres que pour soi-même.
Les
PC, c’est comme les femmes.
Quand on n’en a pas, on ferait n’importe
quoi pour en avoir.
Quand on en a, on se ruine pour les entretenir.
Ne faites jamais confiance à un
ordinateur que vous ne pouvez pas balancer par la fenêtre.
Puisqu’au dire de certains,
l’informatique est trop sérieuse pour être laissée entre les mains des
informaticiens, je me demande si elle n’est pas trop dangereuse entre
les mains d’un non-informaticien.
Plus il est
ridicule
et plus vous vous sentirez ridicule lorsque vous aurez à le
donner.
Plus il est éloigné de votre personnalité,
moins les
autres pourront le trouver,
mais plus vous aurez de chances de
l’oublier.
Plus vous le changez souvent
et moins les autres
pourront le trouver,
mais plus vous aurez de chances de l’oublier.
Dans
tous les cas vous finirez par l’écrire sur un post-it caché dans le
premier tiroir du bureau.
Addendum du Snide :
S’il n’est pas
ridicule, il est inmémorisable et vous aurez l’air ridicule en ayant un
postit collé au dos du clavier.
C’est
après plusieurs jours d’analyse et de développement aboutissant à un
programme modulable bien construit que tout le monde pourra appeler
facilement, et qui répondra à des besoins futurs par des évolutions
faciles, que l’on vous apprend que vous pouvez le jeter à la poubelle
parce qu’un tel programme existe déjà dans un autre service.
Corollaire
: Cet autre programme est bien sûr une merde technique.
"Keyboard not found,
Press any key to continue." ou : "Keyboard error, F11 to resume."
Nous ne croyons pas
que ce soit une coïncidence si le LSD et Unix sont sortis tous les deux
de la même université (Berkeley).
Il y
a deux types d’administrateurs :
- celui qui a fait une grosse
connerie sous root,
- et celui qui va en faire une.
Permettez
aux programmeurs de programmer en anglais, et vous découvrirez qu’ils
ne savent pas écrire en anglais.
Tout programme non
trivial contient au moins un bug.
Corollaire :
Une
condition suffisante pour qu’un programme soit trivial est l’absence de
bogue.
Corollaire étendu :
Le seul programme
garanti sans bug est celui qui ne comporte aucune instruction.
Ajout
de Microsoft au Corollaire étendu :
Windows est un
programme très long.
Dans un
programme informatique, le nombre de bugs est proportionnel à la
factorielle du nombre d’instructions écrites.
Plus la nécessité de revenir en
arrière dans le développement d’un logiciel (à cause de fonctions
modifiées devenues buggées notamment) est criante, plus la dernière
sauvegarde de sûreté est ancienne et périmée.
Énoncé fort :
Oublier
d’archiver régulièrement ses données ou son code entraîne
automatiquement
- que les modifications dans un premier temps seront
longues, pénibles mais parfaites,
- puis entraîneront une catastrophe
imposant un retour en arrière, ce qui provoquera la perte des dites
modifications.
Premier Corollaire :
Les
modifications perdues en revenant à une trop vieille version sont celles
que votre supérieur avait apportées.
Second Corollaire :
Si
vous cherchez à reconstituer certaines des fonctionnalités perdues,
vous en oublierez certaines ; de plus vous obtiendrez ainsi des
incompatibilités subtiles avec les logiciels développés en parallèle
(incompatibilités qui attendront les clients pour apparaître).
L’éditeur de liens
est amplement suffisant pour générer des bugs, ne vous fatiguez pas à
les écrire vous-même.
Plus un bug est découvert
tard dans la journée,
plus il est incompréhensible et doit être vite
corrigé.
(particulièrement les "midnight bugs", croyez en mon
expérience)
Ne testez jamais une
erreur que vous ne savez pas gérer.
(particulièrement sur des
test à chaud sur un serveur de production !)
Résoudre un bug rend
apparent une dizaine d’autres bugs qu’il masquait.
(c'est
affreusement vrai)
L’Exception surgit TOUJOURS
hors des try {} catch().
(logique)
Il
existe.
Plus
petite la modification demandée par l’utilisateur,
plus gros le
boulot nécessaire.
Corollaire : Finalement, il n’en
aura pas besoin.
La vie
serait plus facile si on en avait le code source.
Les médias ne
connaissent qu’un bug, celui de l’An 2000.
L’informaticien rencontre
tous les jours de nouveaux bugs dont les journaux ne parlent pas.
Si votre système
informatique résiste au passage à l’an 2000, alors le 29 février lui
sera fatal.
Corollaire : Les désastres occasionnés
par le 29 février seront bien plus important que ceux prévus, même dans
la pire des hypothèses.