Ce n’est pas commencé tant que ce n’est pas fini

– How much time do you need?
– [Clack!]

Cette citation d’introduction, provenant du film Crimson Tide, est le rêve ultime de tout développeur web. Simplement parce que, bien qu’étant la moins éloquente, c’est la meilleure réponse à donner, la plus précise lorsqu’il est question de débogage. Pour deux raisons:

  1. Pression = ralentissement: il n’y a rien de pire pour la concentration (donc, la résolution finale du bogue) que de se faire déranger toutes les 10 minutes pour savoir si on a bientôt terminé
  2. Débogage = recherche: un bogue est un dysfonctionnement dont la cause est souvent inconnue, donc rarement ciblée, et encore moins définissable dans le temps

Je n’oserais pas ici vous refaire l’analogie de mon précédent article en deux parties sur l’estimation de projets web, mais celle-ci s’applique cependant aussi (et peut-être encore davantage) au débogage.

Ainsi, bien qu’il ne soit pas programmeur, le métier du personnage de Vossler s’y apparente drôlement et sa réponse expéditive est la seule qui vaille dans son contexte. Elle signifie: « je n’en ai aucune espèce d’idée et cesse de me déranger si tu veux que je termine le boulot ». Glorieux!

Pour notre plus grand plaisir, le voici d’ailleurs en pleine action:

On pourrait avoir comme premier réflexe de rigoler un peu de ce jeune Vossler et de coller à sa réponse l’étiquette de la jeunesse insouciante et inexpérimentée… Cependant, le titre de ce billet appuie son attitude. Pour rendre à César ce qui lui appartient, le titre de cet article n’est pas de moi, mais de Carl M. Gilbert de qui j’ai suivi une formation sur la Gestion de projets informatiques chez Technologia.

Il s’agit en fait d’un concept de méthodologie de suivi sur l’avancement des tâches en développement informatique. Plusieurs gestionnaires de projets aiment indiquer la progression de tâches en pourcentage, et souhaiteraient que leur développeur puisse leur dire: « Ce module est terminé à 37% ».

Or, dans de tels domaines (informatique, web…) il n’y a pas de suivi aussi simple et facile que d’affirmer que le module est avancé à 37% ou que 46% du bogue a été trouvé… Ce qu’il faut plutôt se dire dans l’avancement de tâches de ces disciplines abstraites et virtuelles est la phrase suivante:

Ce n’est pas commencé tant que ce n’est pas fini

En bref, l’avancement est simplement à 0% tant qu’il n’est pas à 100%, ou complètement terminé. Pour la simple et bonne raison qu’un avancement de 12% ou de 77% en informatique est toujours temporaire, et surtout, approximatif. On peut croire qu’une tâche est rendue à environ 77% de sa complétion le lundi, puis s’apercevoir le mercredi qu’en fait, deux librairies de codes ont été découvertes par la suite qui impactent la solution et font donc redescendre la progression à 45%.

Un programme n’est pas une maison. Si 14 poutres ont été posées, on ne peut pas prétendre aussi facilement qu’il en reste 4 à poser. Aussi étrange que ça puisse paraitre, dans la progression d’un programme informatique ou d’un développement web, on peut se réveiller un matin et installer l’électricité… pour s’apercevoir que toutes les poutres ont disparues à l’allumage du courant.

Farfelu? Demandez au développeur le plus près de chez-vous… Une simple mise-à-jour d’un petit module peut parfois désactiver l’ensemble du site!

Un programme n’est pas visuel ni physique: on ne peut pas le voir ou le toucher, on ne peut que l’imaginer – le concevoir de façon abstraite et virtuelle. Les résultats attendus encore plus!

Et justement parce que ces mécanismes sont cachés, toute la logique de « bon fonctionnement » en est tributaire. Simple exemple: à la construction d’un garage, il est facile de voir d’un seul coup d’oeil qu’un Hummer ou un tracteur ne rentrera pas par la porte. On qualifierait d’hurluberlu toute personne stipulant que « Ce garage a mal été construit: mon bateau ne rentre pas dedans » car cette constatation aurait pu être prévue dès l’ébauche des plans.

Pour un code ou un programme cependant, il est fréquent (car plus abstrait) de prétendre que « le développeur a mal codé l’application car mon fichier ZIP de 4go ne peut pas être uploadé ». Comme si toutes les « portes » d’un code étaient par définition sensées accepter tous les types d’objets, de tailles ou poids possibles.

Du seul fait que la « porte » est invisible, devient-elle implicitement « magique »? Pour palier à cette réalité, on parle souvent de modularité à l’extrême, même si selon moi la modularité parfaite est une chimère et peut même constituer une perte de temps.

Mais ce sera le sujet d’un autre billet…

Laissez un commentaire