Micro$oft Corporation a annoncé aujourd’hui son intention d’acheter les droits de Dieu Lui-même et d’En poursuivre le développement. Le nouveau produit sera appelé, comme on pouvait s’y attendre, « Micro$oft God », et sera disponible pour le public fin 1998. « Trop de monde se sent loin de Dieu de nos jours », a déclaré Dave McCavaugh, directeur de la nouvelle divisions Religions de Micro$oft. « Micro$oft God rendra notre Seigneur plus accessible, et offrira en plus une interface simple et intuitive, ne le rendant pas plus simple à trouver, mais permettant une communication plus facile. »
La nouvelle ligne de produits Micro$oft Religions incluera une multitude d’add-ons à Micro$oft God, dont :
Micro$oft Crusades : Ce logiciel de conversion récupérera toutes les bonne actions et fichiers de prière de versions précédentes de Dieu, et d’autres produits comme Allah ou Bouddah.
Micro$oft God for the World Wide Web : Ce produit permet de faire communiquer Micro$oft God avec Micro$oft Internet Information Server, rendant notre Seigneur accessible de tout le Web à travers un simple browser. Il introduit plusieurs nouvelles technologies, dont Dynamic Salvation et Active Prayer Pages (APP). Des dons pour les pauvres pourront être ordonnées via un Secure Alms Server.
Microsoft Prayers : A partir d’une interface Windows WYSIWYG, ce produit permettra aux croyants de construire des prières efficaces dans le minimum de temps. Une technologie Secure Prayer Channel permettra de garantir le transfert aux serveurs Micro$oft God, et des Assistants de Prière permettront aux utilisateurs de construire de nouveaux types de prières avec le minimum d’apprentissage.
Micro$oft Savior : Ce produit permettra aux croyants de transférer leurs péchés à sa base de données de Vices. Après un intervalle prédéterminé, ce produit s’effacera du système de l’utilisateur et établira une pure liaison sécurisé vers le serveur Micro$oft God de l’utilisateur.
De plus, Micro$oft devrait annoncer une nouvelle ligne de produits complémentaires pour la nouvelles ligne Religions, qui accroîtra les fonctionnalités du serveur Micro$oft God grâce à une interface utilisateur customisée. Ces interfaces seront basées sur les sectes les plus courantes, permettant aux croyants d’interagir avec le nouveau Dieu de le même manière qu’avec la version précédente. Cette gamme devrait inclure Micro$oft Christianity, Micro$oft Catholicism, Micro$oft Judaism (incompatible avec Micro$oft Savior), etc.
L’éternel rival Netscape dément toutes les rumeurs selon lesquelles il prévoierait de sortir un produit concurrent, Netscape Satanism, qui rendrait les installations de Micro$oft God inopérantes.
Si les restaurants fonctionnaient comme Microsoft…
Client : « Garçon ! »
Serveur : « Bonjour monsieur ! Mon nom est Bill et je suis votre serveur/responsable du service après-vente. Quel est le problème ? »
Client : « Il y a une mouche dans ma soupe ! »
Serveur : « Essayez encore, peut-être que la mouche disparaîtra d’elle-même. »
Client : « Non. Elle est toujours là. »
Serveur : « Moui… C’est peut-être que vous n’utilisez pas correctement votre soupe. Essayez donc de la manger avec une fourchette, par exemple. »
Client : « Hmmm… Même avec une fourchette, la mouche est toujours là. »
Serveur : « Moui… (monsieur est un client difficile) Il est possible que votre soupe soit incompatible avec le récipient que vous utilisez. Quelle sorte de récipient utilisez-vous, monsieur ? »
Client : « Un bol à SOUPE ! »
Serveur : « Tiens, curieux: ça devrait fonctionner. Peut-être s’agit-il plutôt d’un problème de configuration. Comment le bol qu’on vous a amené a-t-il été présenté ? »
Client : « Ben… Vous l’aviez posé sur une soucoupe. Mais j’avoue que je ne vois pas ce que ça peut… »
Serveur : « TRÈS BIEN ! Vous rappelez-vous de TOUT ce que vous avez fait avant de remarquer qu’il y avait une mouche dans votre soupe ? »
Client : « Je me suis assis et j’ai commandé cette bon dieu de soupe du jour ! »
Serveur : « Avez-vous pensé à faire une mise à jour et adopter la soupe du jour la plus récente ? »
Client : « Vous avez plus d’une soupe du jour par jour ? »
Serveur : « Bien entendu, monsieur. Le soupe du jour change toutes les heures. »
Client : « Bien. Et quelle est la soupe du jour en ce moment ? »
Serveur : « La soupe du jour est actuellement… la soupe aux tomates. »
Client : « Parfait ! Amenez-moi la soupe aux tomates, et l’addition par la même occasion. »
(le serveur s’en va et revient avec la soupe et l’addition)
Serveur : « Voilà, monsieur. La soupe du jour, et l’addition de monsieur. »
Client : « C’est de la soupe aux pommes de terre. »
Serveur : « Hem, en effet. La soupe aux tomates n’était pas encore prête. »
Client : « Beuh. Cela ne fait rien. Merci. »
(le serveur s’en va)
Client : « Garçon, il y a un moucheron dans ma soupe ! »
Serveur : « AARH ! »
Client : « Je veux revoir mon kangourou basque. »
L’addition :
Soupe du jour. ……. 10.00 Mise à jour vers une nouvelle soupe du jour 05.00 Accès au service après-vente 04.00
#include #include #include /* Librairie de Connexion du Réseau Microsoft */ #include /* Pour la cour de justice */ #define dire(x) mensonge(x) #define utilisateurdordinateur TOUS_VEULENT_ACHETER_NOTRE_LOGICIEL_BOGUE #define année_prochaine bientôt #define le_produit_est_déjà_prêt_à_partir, autre_version_beta void main() { if (dernière_version__window_d_au_moins_un_mois) { if (il_y_a_encore_des_bogues) marche(corriger_les_bogues); if (les_ventes_sont_en_dessous_d_un_certain_point) lever(RUMEURS_AU_SUJET_D_UNE_NOUVELLE_VERSION_SANS_BOGUE); } il(tout_le_monde_parle_à_propos_d_une_nouvelle_version) { faut_faire_de_fausses_promesses(ça_sera_multi_tâches); /* Appel standard, dans mensonges.h */ if (les_rumeurs_vont_bon_train) faire_de_fausses_promesses(ça_sera_plug_and_play); if (les_rumeurs_continuent_a_aller_bon_train) { temps_marche=mur; dire(« Ça sera prêt dans un mois »); ordonner(programmeurs, arreter_de_corriger_les_bogues_de_l_ancienne_version ordonner(programmeurs, commencer_le_lavage_de_cerveau_pour_une_nouvelle_version; ordonner(directionmarketing, permission_de_divulguer_des_non_sens); logicielvapeur=TRUE; break; } } switch (de_sales_questions_émanent_de_la_presse) { case LORSQUE_CA_SERA_PRET: dire(« ça sera prêt dans », aujourd_hui+30_jours, » nous sommes en phase de test »); break; case LORQUE_LE_PLUG_AND_PLAY_FONCTIONNERA: dire(« Oui ça tourne »); demander(programmeurs, pourquoi_est_ce_que_ca_ne_tourne_pas); prétendre(il_n_y_a_pas_de_problème); break; case QUEL_EST_LE_MATERIEL_MINIMUM_REQUIS: dire(« ça tourne sur un 8086 à la vitesse de l’éclair grâce à » » l’architecture 32 bits »); informer(INTEL, « Les ventes de Pentium vont pulvériser les sommets »); informer(SAMSUNG, « Commencez à faire une nouvelle mémoire » « parce que tous ces clients auront besoin d’au moins 32 megas »); informer(QUANTUM, « Remerciez notre logiciel monstre qui va tripler vos ventes »); donner_un gros_bonus(INTEL, SAMSUNG, QUANTUM); break; case MICROSOFT_PREND_TROP_D_IMPORTANCE: say(« Oh non, nous sommes simplement en train de rendre le monde meilleur pour tous »); enregistrer(journaliste, Gros_Livre_de_Bill); when(il_est_grand_temps) { arrêter(journaliste); lavage_de_cerveau(journaliste); when(journaliste_dit_que_windows95_est_sans_bogue) { ordonner(journaliste, « écrivez un bel article objectif »); libérer(journaliste); } } break; } while (logiciel_vapeur) { date_d_introduction++; /* Délai */ if (plus_personne_ne_croit_à_une_nouvelle_version) break; dire(« ça sera prêt dans « ,aujourd_hui+UN_MOIS); } libérer(version_beta) while (tous_en_ont_assez_de_notre_logiciel_bogué) { compte_en_banque_de_bill += 150*mégabucks; libérer(nouvelle_version_supérieure); introduire(plus_de_besoin_matériel); if (les_clients_rapportent_des_problèmes_d_installation) { dire(« C’est un problème matériel et non un problème logiciel »); if (le_client_confiant_dit_mais_vous_avez_promis_du_plug_and_play) { ignorer(client); ordonner(service_secret_microsoft, « Gardez un oeil sur ce bâtard »); } } if (compte_en_banque_monumental_de_bill && mariage_date de_deux_ans ) { divorcer(femme_qui_était_belle_lorsque_je_l_avais_épousée); faire_des_vagues(dollars, à_la_fille_sexy); épouser(jeune_blonde_vierge_avec_de_gros_lolos); déflorer(jeune_blonde_vierge_avec_de_gros_lolos); if (les_lolos_commencent_à_tomber) virer(les_lolos_commencent_à_tomber); /* Elle est encore vierge??? */ } if (il_y_a_une_autre_société_qui_monte) { voler(leurs_idées); accuser(societé, d_avoir_volé_nos_idées); louer(un_paquet_d_avocats); /* dans procès.h */ attendre(jusqu_à_ce_que_autre_société_ne_puisse_plus_engager_de_poursuites); racheter(l_autre_société); } } /* Maintenant tout le monde realise que nous avons vendu un logiciel bogué et ils sont en colère contre nous */ commander(chirurgien_plastique, donner_à_bill_l_apparence_d_un_pauvre_bâtard); acheter(une_belle_petite_ile); louer(un_harem); rire(de_tout_le_monde_d_avoir_attendu_année_après_anneée_une_nouvelle_version_incomplète); } void corriger_les_bogues(void) { charger(un_paquet_de_fric)
1 ) Un micro-ordinateur est obsolète dès son déballage.
2 ) Une application pleinement satisfaisante doit toujours être upgradée… Et la mise à jour est toujours boguée.
3 ) Quand un logiciel est inutile, il faut une formation.
4 ) Tout programme, s’il fonctionne, est obsolète.
5 ) Tout autre programme coûte plus cher et prend plus de temps.
6 ) Si un programme est utile, il sera remplacé.
7 ) Si un programme est inutile, il faudra le documenter.
8 ) Tout programme grandira de manière à occuper tout l’espace mémoire disponible, même si on ne le démarre jamais.
9 ) Le prix d’un programme sera proportionnel à la lourdeur de ce qu’il donne en sortie.
10 ) La complexité d’un programme croîtra jusqu’à ce que le programmeur lui-même n’y comprenne plus rien.
11 ) Tout programme non trivial contient au moins un bug.
12 ) … Aucun programme n’est trivial.
13 ) Les erreurs indétectables sont en nombre infini, contrairement aux erreurs détectables dont le nombre catalogué est très limité.
14 ) Si on ajoute un homme à un projet en retard, cela ne fera qu’ajouter du retard.
15 ) Faire disparaître un message d’erreur est une utopie : vous n’avez simplement pas encore trouvé celui qui l’a remplacé.
16 ) La fonction annuler n’est jamais disponible quand vous en auriez besoin.
17 ) Ce n’est qu’après avoir essayé tout le reste, qu’on lit la documentation…
18 ) … C’est à ce moment qu’on se rend compte qu’on l’a jetée avec l’emballage.
19 ) Dès que vous quittez l’imprimante des yeux, elle a un problème.
20 ) C’est généralement lorsque le disque dur plante qu’on se rend compte qu’on a oublié de le sauvegarder…
21 ) … Sinon, c’est en le sauvegardant qu’on l’a fait planter.
22 ) La zone de danger pour un ordinateur dépend de la longueur de son cordon d’alimentation.
23 ) Une des raisons qui explique 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.
24 ) Si les ordinateurs deviennent trop puissants, on peut toujours les organiser en comités.
25 ) A 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).
26 ) 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 « anoblit », et personne n’ose le critiquer.
27 ) Les ordinateurs ne sont pas intelligents. Mais ils pensent qu’ils le sont.
28 ) Les vieux programmeurs ne meurent pas. Ils se branchent simplement à une autre adresse.
DEUXIEME LOI DE WEINBERG :
Si les constructeurs construisaient les bâtiments de la manière dont les programmeurs écrivent les programmes, le premier pivert qui passerait détruirait la civilisation.
LOI COMMUNES DE LA BUREAUTIQUE ET DE LA PROGRAMMATION REUNIES :
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.
LOIS DE L’ECRITURE D’UN PROGRAMME :
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.
1 ) Tout programme, quel qu’il soit, dès qu’il est commercialisé est obsolète.
2 ) Tout nouveau programme coûte plus cher et est plus lent à faire tourner que l’ancien
3 ) Si un programme est très utile, il devra être changé par un autre.
4 ) Si un programme est inutile, il faudra lui faire une documentation
5 ) Tout programme lors de son lancement aura tendance à remplir toute la RAM disponible
6 ) La valeur d’un programme est inversement proportionnelle à la taille des documents qu’il génère.
7 ) 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.
TROISIEME LOI DE GREER :
Un programme informatique fait ce que vous lui dites de faire, pas ce que vous voudriez qu’il fasse.
POSTULATS DE TROUTMAN :
1 ) Les jurons sont les seules expressions comprises par tous les programmeurs.
2 ) Ce n’est que lorsqu’un programme sera commercialisé depuis 6 mois que les plus graves erreurs seront détectées.
3 ) Les cartes de contrôle de travail qui doivent être classées dans un ordre précis seront classées dans le désordre.
4 ) Des cassettes supposées être interchangeables ne le seront pas.
5 ) 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 des mauvaises valeurs par le programme.
6 ) Si une installation test fonctionne parfaitement, tous les systèmes qui en dépendent vont planter.
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.
LOIS DE GOLUB DE LA DOMINATION INFORMATIQUE :
1 ) Des objectifs de projet flous sont pratiques pour éviter l’embarras d’une estimation des coûts correspondants.
2 ) 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.
3 ) L’effort à fournir pour corriger le cap d’un projet s’accroît géométriquement avec le temps.
4 ) Les équipes de projets de développement détestent les briefings hebdomadaires sur l’avancement du projet… parce qu’ils mettent en évidence que le projet n’avance pas.
PREMIERE LOI DE GILB SUR LA CONFIANCE :
On ne peut pas compter sur les ordinateurs, mais encore moins sur les humains.
Les dix commandement du programmeur : ou Comment Programmer sans stress.
1 ) Des Bugs tu ne t’inquièteras pas. Les bugs dans votre logiciel sont actuellement des fonctionnalités particulières.
2 ) Corriger le problème tu ne feras pas. Vos utilisateurs auront plus de chance de gagner au loto que de tomber encore sur ce bug.
3 ) Le traitement des erreurs tu ne géreras pas. La gestion des erreurs ne signifie quelque chose que pour les gens enclins aux erreurs. Ni vous-même ni vos utilisateurs ne sont enclins à faire des erreurs.
4 ) Des restrictions, tu n’imposeras pas. Laisser l’utilisateur entrer n’importe quoi comme donnée, n’importe où, n’importe quand. C’est ce que l’on appelle être TRÈS convivial.
5 ) Tu n’optimiseras pas. Les utilisateurs seront reconnaissant d’obtenir une information quel qu’elle soit. Ils ne s’inquiètent ni de la vitesse, ni de l’efficacité.
6 ) Tu n’aideras pas. Si un utilisateur n’est pas capable d’utiliser seul votre programme, ils est trop abruti pour mériter votre programme de toutes façons.
7 ) Tu ne documenteras pas. La documentation ne sert qu’a annoncer de futures modifications. Comme votre programme est parfait des la première version, il n’aura jamais besoin d’être modifié.
8 ) Tu ne te presseras pas. Seuls les patrons ou les très mignonnes utilisatrices ont besoin d’un programme dans les temps.
9 ) Tu ne réviseras pas. Votre interprétation des spécifications est toujours correcte. Vous connaissez les besoins des utilisateurs mieux qu’eux.
10 ) Tu ne partageras pas. Si des programmeurs ont besoin d’une partie de votre code, ils n’auront qu’à l’écrire eux-mêmes.
