| Témoignage |
 Écrivez à AILES ! |
 Retour vers l'article (multiples sens de Bug) |
|
Voici quelques détails et illustrations complémentaires sur l'article de Laurent Bossavit concernant les multiples significations du terme bug. Vous noterez au passage l'exceptionnel état de conservation de cette pôv' mite, qui aura bientôt 50 ans... |
Le "bug originel"
(cf. De
la signification d'un Bug - Laurent Bossavit -)
Il remonte à 1945 et cet insecte se trouve religieusement
conservé au Naval Surface Warfare Center
Computer Museum à Dahlgren, Virginia, depuis 1988. ([Navy])
Le 9 Septembre 1945, ces opérateurs découvrent la mite ("moth") coincée entre les pointes du relais n° 70, panneau F, sur le coup des 15h45. Les relais de l'époque étaient constitués d'une lame repoussée par un ressort et attiré par un électro-aimant. Ainsi, la dite lame pouvait établir un contact entre l'une ou l'autre pointe, suivant la présence ou non de courant dans l'électro-aimant.
Ils ont ainsi "debuggué" l'ordinateur... the rest is history.
Qu'y a-t-il dans un mot ? (cf. De la signification d'un Bug - Laurent Bossavit -)
Cette question anodine, ici abordée dans le cadre du terme "bug", renvoie à l'obligation de bien expliciter les termes que l'on emploie.
Au passage, on notera que cela est "compliqué", car peu naturel dans notre culture française, basée sur l'implicite...
Toutes les process de modélisations (RUP, VUP, MDA...) préconisent l'utilisation d'un glossaire, qui précise chacun des termes clés issus du cahier des charges (donc de l'univers du client et de son vocabulaire).
On connaît également le poids crucial de chaque mot lors de la rédaction de spécifications de besoins, où chaque phrase compte, car le document final constituera un document contractuel, qui devra être respecté.
On retrouve encore un soucis de définition pour dissiper tout malentendu dans les normes rédigées par le w3c, et qui rappellent systématiquement ce qu'ils entendent par les termes "shall", "must", "should", "could" (cf. Informaticien et Français ? - Implicitement - Dur!).
Bref, une telle démarche de clarification des termes est monnaie courante dans notre métier... à l'exception des termes employés par les premiers intéressés, les développeurs eux-même! Si une telle démarche est recommandée pour les termes venant du client, pourquoi les programmeurs ne s'appliquent-ils pas cette recommandation de bon sens à eux-même et à leur propre vocable ? L'article de Laurent Bossavit est là pour montrer les dangers de l'absence d'une définition claire du terme "bug", danger illustré par le paragraphe suivant.
Les mots révèlent les cultures (cf. De la signification d'un Bug - Laurent Bossavit -)
Il est important de préciser que les "cultures" dont parle Laurent Bossavit ne sont pas des cultures "nationales" (comme la culture française, évoquée dans le dossier Management, avec ses aspects implicites et verticaux).
Il s'agit plutôt de l'ensemble de croyances et d'habitudes d'un groupe de travail donné, comme celui des développeurs qui ont pour "principe" de croire en l'inévitabilité du "bug", cette fatalité aussi implacable que les impôts ou la mort.
Cela met bien en évidence une caractéristique majeure du bug, - et qui est à l'origine de l'article de Laurent - : le bug ôte toute responsabilité.
Lorsqu'il s'agit vraiment de corriger les bugs, [TeamShare] préfère parler de "defect" en prenant bien soin de préciser qu'il ne s'agit pas de bug. Extrait :
« Trop de gens impliqués dans le processus de développement aiment à voir les défauts comme des bugs, parce que cela leur permet de croire plus facilement que les défauts sont des entités vivantes qui se mettent d'elles-même dans le code. » [cf. origine animale du bug, ci-dessus]
« Tom DeMarco le présente ainsi : "Un bug est quelque chose qui rampe par sa propre volonté dans votre code et qui y met le boxon. Cela ne rejaillit pas sur vous. Cela peut arriver à n'importe qui. Un défaut vient de notre propre faute." »
Pour bien voir
Décollage ! | Présentation du site web "AILES" |
Infos générales | articles "Informatique"