J’ai un vice[1] : les signatures automatiques. Chaque mail de ma part est orné en signature d’une citation issue de mon site, d’une boutade glanée sur le net (dont énormément de Slashdot), d’un extrait de mes pages sur la Loi de Murphy... choisie aléatoirement par fortune. Une collection de ce genre est forcément privée, pleine de préjugés et inclinaisons personnelles, mais je tiens à en faire partager le maximum de monde. Aujourd’hui, une partie de mon fichier info_developpement.txt, avec traduction en français. Chacune de ces citations peut donner lieu à des mégaoctets de discussions et débats... Et je me connais, je ne résisterai pas à l’envie de commenter. (Les suggestions sur des améliorations de traduction sont les bienvenues).


As soon as we started programming, we found to our surprise that it wasn’t as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.

Dès nos début en programmation, nous avons découvert à notre surprise qu’il n’était pas aussi facile que nous pensions d’obtenir un programme. Il fallait découvrir le débogage. Je peux me souvenir de l’instant exact où j’ai réalisé qu’une grande partie de ma vie à partir de ce moment allait être dépensée à chercher des erreurs dans mes propres programmes.

Maurice Wilkes, 1949

Donc même un des Pères Fondateurs de l’informatique, d’une époque où les maths étaient plus utilisés que la programmation par essai-erreur, a été surpris par le temps passé à déboguer des logiciels un million de fois plus simples et limités que ceux de maintenant. Diantre.


Because, at my heart, I’m a programmer,
and I hate the thought of doing something twice...


Au plus profond de mon cœur je suis un programmeur,
et je hais la pensée de faire quelque chose deux fois...

John Whitlock, Slashdot, 09 juin 2002

Un de mes proverbes. Faire c’est bien, refaire me gave. Je dois être un peu comme Lévi-Strauss qui a été prof deux ans, le temps de s’apercevoir qu’il devrait refaire le même cours chaque année. Et si je ne répugne pas à être formateur, enchaîner des sessions identiques me porte vite sur les nerfs.


Many years ago, using flow charts was a requirement in many software jobs. (For those of you less than 40, a flow chart was a stylized picture of small-scale flow control: little diamonds for ‘if’, square blocks for computations, other funny shapes for IO, etc. All connected by arrows.) Flow charts were pretty useless, but you had to produce them, so we built tools that parsed Fortran77 and generated nice flow charts. No one actually used them, but they looked nice hanging outside your office, especially if you had access to a color flatbed plotter.

Il y a bien des années, les organigrammes étaient obligatoires dans nombre de travaux informatiques. (Pour ceux d’entre vous de moins de 40 ans, un organigramme était un dessin stylisé à petite échelle du processus : des des petits losanges pour « si », des carrés pour les calculs, d’autres formes bizarres pour les E/S, etc. Tous connectés par des flèches.) Les organigrammes étaient à peu près inutiles, mais il fallait les produire, et donc nous avons construit des outils pour analyser du Fortran77 et générer de jolis organigrammes. Personne ne les utilisait vraiment mais ça faisait joli accroché hors du bureau, surtout si vous y aviez accès à un traceur couleur. ).

mikec, Slashdot, 15 janvier 2002

Deux leçons là-dedans :

  1. la documentation inutile ne date pas d’hier : en l’occurence il s’agit d’une description de l’algorithme utilisé dans un langage peut-être utile aux tous premiers informaticiens qui manipulaient des câbles au lieu du C, mais le développeur d’aujourd’hui comprend plus vite le code que le graphique illisible au-delà de cinq boucles ; les seules documentations que je considère utiles sont celles sur les grandes lignes du logiciels, les spécifications fonctionnelles (quasiment des modes d’emploi), l’historique, quelques notes sur pourquoi on a procédé de telle ou telle manière dans le code ;
  2. s’il y a besoin de documentation technique et que le code lui-même ne suffit pas, le mieux est effectivement de faire générer cette documentation par l’entité la plus à même de le faire rapidement, sans erreur et sans traîner les pieds, à savoir la machine elle-même (de nos jours on utilise par exemple javadoc ou epydoc).

The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones.

Ce qu’il y a de mieux avec la programmation orientée objet, c’est que ça peut faire ressembler les petits problèmes simples aux grands problèmes complexes.

Trouvé sur Slashdot


Writing software is not like building bridges because halfway through the project some dumbass from marketing doesn’t come down and tell you that concrete is out and so it needs to be a steel bridge. Oh, and those tacky cables have got to go — the focus group hated them.

Écrire des programmes, ce n’est pas comme construire des ponts, car un con du marketing ne vient pas vous dire que le béton est out et qu’il faut un pont en acier. Et puis ces câbles gluants doivent disparaître — le focus group les a détestés.

john@iastate.edu, Slashdot, 05 novembre 2001

J’ajoute qu’en général la maquette du pont n’est pas utilisée pour faire réellement passer trains et camions sur le pont, et que le commanditaire ne décide pas au dernier moment de tripler la largeur et la profondeur du fleuve.

Notes

[1] Entre mille autres.