C’est toujours au moment où je m’y attends le moins que mes collègues m’épatent. Je rentrais gentiment de la cantine, quand un collègue, resté au bureau bien à l’abri du croque-monsieur aux quatre huiles, m’alpague au vol.

Lui – Tiens, j’ai trouvé un défaut là, sur le portage winrt.

Moi – Ha ?

Je sais, j’ai l’air de manquer d’intérêt, mais d’une, je n’ai pas encore versé mon café, deux, ce n’est pas très étonnant que le portage winrt soit buggué, puisque c’est lui qui l’a fait et validé.

Lui – Oui, j’avais une trace « Underflow error », et puis les attentes de tâches de fonctionnaient pas. Enfin là, c’est corrigé. Je vais envoyer une nouvelle version de la lib compilée par mél.

Moi – Le code est en conf ?

Lui – Euh non, pas là, enfin pas encore.

Agile jusqu’au bout des ongles.

Moi – Je préfèrerai qu’on ouvre un Fait Technique, histoire qu’on trace le défaut, et qu’on corrige et livre proprement. Pourquoi, c’est urgent, le client est bloqué ?

Lui – Non, non, le client ne l’a pas encore vu.

Alors effectivement, il est urgent de se tirer une balle dans le pied.

Lui – Non mais t’as raison, je vais faire un FT, comme tu as dit.

Moi – Voilà, je livrerai lundi, au calme, ne t’inquiète pas. Par contre, je ne sais pas comment on compile le portage winrt, tu le feras ?

Lui – Euh, c’est que, je dois partir en vacances.

Comme quoi, répéter toutes les semaines qu’il faut partager la manière de compiler le portage winrt en point d’avancement hebdomadaire est aussi efficace qu’un physicien dans un harem.

Le Chef, qui doit également partir en vacances, et a initié le portage – Oui non mais regarde, c’est facile, tu prends la tablette là, tu branches un clavier, une souris, une alim’, tu te connectes là, tu vires le clavier ou la souris pour brancher une clef USB et monter les sources, tu redébranches, t’ouvres Visual, puis bon voilà hein, tu verras.

Moi – Les libs compilées, elles sortiront où ?

Le Chef – Ha ben je … Il faut regarder les attributs du projet.

Lui – Ou alors c’est dans C:

Moi – Bien. Je me débrouillerai je crois. Et c’était quoi ce défaut ?

Si j’échoue à compiler, je ne crois pas franchement qu’on pourra m’en vouloir après une formation aussi poussée.

Lui – En fait, les tâches en attente restaient bloquées. La tablette est trop lente. Quand on fait un appel du genre « réveille-moi dans 10 ms », le temps qu’on rentre dans la fonction, les 10 ms sont écoulées, du coup on a une échéance dans le passé, et on est bloqué.

Moi – Classique. C’est exactement le même problème qu’on a eu sur deux autres portages, mais OK. Et comment as-tu corrigé ?

Lui – En fait, avant, on ne vérifiait pas le code d’erreur de la soustraction entre l’échéance et la date courante. Comme la tablette est trop lente, la date courante est toujours plus grande que l’heure absolue de l’échéance, donc la soustraction échoue systématiquement, en produisant « Underflow error » et un code de retour FAILURE. Donc maintenant, on vérifie le code de retour.

Comment ? Dans un logiciel temps-réel embarqué, on devrait s’assurer en permanence que « tout marche bien navette » ? J’ai failli faire une descente d’organe.

Moi – Tu ferais mieux de faire une comparaison entre les deux dates, et en fonction tu fais l’appel système ou tu restes passant. Sinon tu vas produire des traces pour rien.

Lui – Ha ! mais non, pas de soucis : je me suis dit que ça ferait faire deux fois la comparaison, alors plutôt, j’ai testé le code de retour de la soustraction, et puis surtout, j’ai supprimé l’émission de la trace « Underflow error ». Tu vois, plus de problème.

Excellent ! Tu supprimes la trace qui t’a permis de pointer du doigt ton problème, et tu joues du tractopelle dans mon jardin à la française, mais continue ! Tu veux pas déféquer sur mon bureau, si ?

Moi – Certainement pas ! C’est un principe de conception ! Quand une fonction ne remplit pas son office, elle trace un problème, vu qu’en C, rien n’oblige à vérifier les codes de retour. ON NE SUPPRIME PAS LES TRACES DE DEBUG. Je pense l’avoir déjà expliqué un certain nombre de fois !

Lui – Oui mais j’avais plein de fois la trace alors qu’il n’y avait pas de problème.

Moi – Ha ben si, y’a un gros problème : comme tu peux vérifier avant d’appeler ta fonction si elle ira au tas ou pas, tu dois le faire, et pas attendre qu’elle échoue pour te dire qu’il y a un problème. Il est prédictible ton problème, c’est fini la programmation à base d’exception, hein, tu peux pas espérer en croisant les doigts que allez, on sait jamais, 2 – 5, cette fois, ça pourrait être positif, va savoir. Sur ce, bonnes vacances, moi, je pars en week-end.

Non mais.

Il existe encore des idéalistes dans le développement logiciel. Attention, des vrais hein, pas des jeunes à peine sorti de l’école, tout bouffis de suffisance, persuadés qu’ils sont que le savoir qu’ils ont accumulé fera d’eux des gagnants et des meneurs. Moi je parle de gens qui y croient encore, et ce malgré leurs six mois d’ancienneté dans n’importe quelle SSII.

Récemment, j’ai rencontré un collègue ivre de joie de participer à un paléogiciel maison afin de le conchier définitivement d’y apporter son lot de corrections en tout genre. Premier constat, on est au moins aussi fort que dans de grands groupes mondiaux.

Nul besoin de test quand on a des utilisateurs. – B. Gates, escroc

Prise en main du logiciel, étude du code induit par spaghetto-génèse accélérée, régalade en tout genre, et soudain, LA révélation : « mais ! ça ne peut pas marcher ! » Hélas ! Que de temps perdu !

Il y avait plus simple ! – B. Renard, boulier

Et oui ! Une simple question aux utilisateurs aurait suffit, comme le lui apprendra la suite de l’aventure. À la question « mais ça, vous vous en servez comment ? », la réponse fuse : « Oh, ça ? On ne s’en sert pas, ça ne marche pas. » Autant dire que la fonctionnalité est essentielle. Suffisamment pour lui éviter d’être supprimée en tout cas. La corriger ? Non plus. On n’est pas payé à corriger des défauts qui ne sont pas vus par les clients. De l’intérêt de faire des formulaires de rapport de défauts bien abscons.

Ho ! non, encore un 'extern' devant une fonction dans un .h

Retour dans les profondeurs du code lasagnesque, version supplément béchamel et pâte trop cuite. Face aux interfaces multiples, redondantes et « toutes pourries » (sic), le collègue, enfin, le sous-traitant avec qui mon humanisme m’a forcé à sympathiser pour qu’il ait au moins une lueur de joie dans sans triste journée d’esclave sur-payé, le collègue, donc, a une idée du tonnerre : proposer sa propre interface. Il branchera les anciennes fonctionnalités dessus quand il aura fini, et il pourra faire disparaître le code de la honte.

Mais c’est super ! C’est un peu vite oublier que le code dont il essaie de se débarrasser est lui-même issu d’autres idéalistes intérimaires qui ont dû tout laisser en plan à mi-chemin parce que leur mission prenait fin brutalement, afin qu’ils puissent démontrer toute l’étendue de leur talent sur ce nouveau poste de plieur de trombone à Calais. Je ne vois pas d’autre raison, franchement.