LMDP - Les petites phrases

Aujourd'hui, je vais m'attaquer à ces petites phrases, ces commentaires, qui peuvent prêter à sourire, mais qui masquent souvent un risque réel,. Et ça fait froid dans le dos. Exemple typique, la première de cette série...

Petit avertissement avant de commencer: tout ça s'est réellement passé

"Je me disais bien que ça ne fonctionnerait pas"

Le contexte est le suivant: un développeur avait terminé (c'est ce qu'il prétendait) le développement d'une application Web en Java et l'avait déployée dans l'environnement d'acceptance. Un collègue architecte effectue alors quelques tests et réussit à planter l'application (le beau plantage, avec affichage de l'exception sur l'écran de l'utilisateur).
Il appelle le développeur et lui montre: "là j'entre ça et je clique là et… (boum)". Le développeur contemple l'écran avec un petit sourire: "ah ça… Je me disais bien que ça ne fonctionnerait pas."

"Je n'en reçois que 170"

Attention, signe d'incompétence.

Cette phrase, c'est le cri d'alerte lancé par un responsable d'équipe de développement aux administrateurs DB. En temps qu'architecte, je suis en copie du mail (et de la réponse qui va suivre).

Ce responsable explique dans son mail qu'il interroge une base de données, mais en limitant le nombre de lignes renvoyées à 200. Il fournit aussi sa requête SQL. Son inquiétude vient du fait que le résultat n'est pas celui attendu: au lieu de recevoir les 200 lignes, il n'en reçoit que 170.

Réponse des DBA à l'intéressé: "ta table ne contient que 170 lignes".

"L'application sera multilingue grâce à…"

C'est l'histoire d'une application qui devait être personnalisée en fonction de la société qui l'utilisait: couleurs, logos et langues.

Au cours de nos premières réunions d'architecture, nous avons expliqué que le problème des chartes graphiques différentes serait résolu par l'utilisation de CSS différentes. Quant à la question du multilinguisme, elle était à la fois trop simple et trop complexe pour ces réunions préparatoires et fut laissée de côté.

Un directeur informatique suivait ces réunions d'architecture.

Au cours d'une présentation faite à l'ensemble du management, alors qu'on demandait aux architectes d'expliquer leurs premières constations, c'est ce directeur, sans doute pressé de se mettre en avant, qui prit la parole.

Il expliqua entre autres que "l'application serait multilingue grâce à l'utilisation de CSS adéquats". Les architectes, eux, regardaient leurs chaussures et se mordaient les joues pour rester sérieux.

"Même quand on connaît, c'est compliqué"

Alors qu'un chef de projet demandait à un responsable d'équipe de développement (le même qui voulait ses 200 lignes) de montrer le code d'une de ses applications à un développeur d'une autre équipe, il essuya un refus justifié en ces termes: "non, c'est trop compliqué, même quand on connaît, c'est compliqué".

Non mais… sérieusement quoi…

Pour terminer cette série de perles, voici trois petites phrases lues dans des rapports de progression, des documents très officiels sur l'état d'avancement du projet, envoyés au comité de pilotage et écrits par le chef de projet. Au fait, ce chef de projet était... le responsable d'équipe déjà cité.

"L'analyse fonctionnelle a débuté plus sérieusement la semaine du 4 mars". Et avant, c'était quoi? Une partie de rigolade?

Quatre mois plus tard, sur le même projet: "Un rapport de progression aurait dû être produit le 16 mais il est resté dans mes brouillons, mauvais point pour le chef de projet (c'était mon dernier jour avant mes vacances)".

Et finalement, 8 mois après le premier rapport, l'appréciation globale du projet est "moyenne". Pourquoi? C'est expliqué dans le rapport: "nous sommes loin d'être en avance". Et un peu plus loin, "cette semaine de test risque de s’étendre sur deux semaines".

Qui a dit que l'informatique n'était pas drôle?

LMDP: pas la bonne ligne

Ca faisait un bout de temps que j'avais envie de démarrer cette série. LMDP, c'est pour "Le meilleur du pire". Bon, je sais, comme nom de série, il y a sans doute mieux...

Depuis quelques années, je tiens une espèce de best of de pires bêtises que j'ai vue dans le milieu de l'informatique. Bien sûr, il y a du code, mais aussi de la gestion de projet (au sens large) et quelques inclassables.

C'est d'ailleurs par l'un d'eux que je vais commencer.

Le contexte

Tous les trois mois, nous migrons des clients d'une ancienne application vers une nouvelle. Tous les trois mois, un responsable de la migration nous demande de lui fournir des scripts SQL afin de reprendre les données de l'ancienne application vers la nouvelle.

Jusque-là, rien de très particulier.

Pour nous "aider", il extrait lui-même les données dans un fichier Excel. Chaque ligne du premier onglet représente une ensemble de données à insérer, parfois dans une, parfois dans deux tables.

Pour un des types de données, j'ai écrit une formule qui, copiée dans le deuxième onglet du document autant fois qu'il y a de lignes dans le premier, se transforme en requête SQL d'insertion. Je ne ferais pas ça tous les jours, mais bon...

Initialement, j'ajoutais la formule moi-même au fichier fourni par le responsable (appelons-le Antoine), mais comme ce n'est pas mon boulot, je lui ai dorénavant envoyé la formule afin qu'il bricole lui-même son fichier Excel. Et cela fonctionne très bien ainsi depuis plusieurs trimestres.

Première boulette

Quand je dis que tout se passe bien, ce n'est pas tout à fait vrai.

Le trimestre dernier, Antoine a demandé l'exécution de requêtes une première fois, puis s'est rendu compte que son fichier n'était pas complet, l'a complété, a généré les requêtes une nouvelle fois et a demandé une seconde exécution de ces requêtes.

Conséquence, des lignes dupliquées dans la base de données. Vous me direz que s'il y avait eu des contraintes d'unicité, ça ne serait pas arrivé, et vous auriez raison. A notre décharge, l'application vérifie que les lignes n'existent pas déjà et il paraissait impossible que ça arrive... jusque-là.

Nous décidons donc de revoir les requêtes de vérifier si la ligne n'existe pas déjà. J'effectue cette modification dans le dernier fichier fourni par Antoine.

Toujours dans l'urgence

Aujourd'hui, vers 10h, Antoine nous demande d'exécuter les scripts de migration. Petit vent de panique: la migration n'est normalement prévue qu'à la fin du mois et la moitié de l'équipe est d'ailleurs en congé, en particulier celui qui s'occupe d'une grande partie des migrations. Nous voudrions attendre mais rien à faire, les données doivent être migrées pour 12h, heure à laquelle les clients auront accès à la nouvelle application.

Néanmoins, on s'organise pour pallier le manque d'organisation d'Antoine...

Je lui rappelle que j'ai modifié la formule Excel. Il vient la voir sur mon PC, dans le fichier Excel de la dernière migration et me dit qu'il va m'envoyer le fichier, ce à quoi je réponds que je vais plutôt lui envoyer la formule. Avant qu'il ait eu le temps de réagir, j'ouvre un nouveau message et y copie la formule.

Là, il réagit et me dit: "envoie-moi aussi le fichier". Je lui réponds: "Tu dois plutôt utiliser la formule, c'est un ancien fichier". Il insiste et je la joins à l'e-mail.

Me voilà tranquille.

Deuxième boulette

Dix minutes plus tard, Antoine envoie un mail à l'équipe système pour exécuter un fichier de requêtes sql en production. Je suis en copie du mail.

Cinq minutes après, réponse de l'équipe système annonçant que les requêtes n'ont pas pu être exécutées.

Je jette un oeil au log d'erreur, puis aux requêtes envoyées par Antoine, et il apparaît que la dernière requête est incorrecte. Les paramètres qui devraient être insérés sont absents. J'en déduis que la formule a été copiée sur une ligne de trop, une ligne qui ne correspond à aucune donnée dans le premier onglet du fichier Excel.

Quelques minutes plus tard, nouveau mail d'Antoine, avec un fichier SQL, correct celui-là.

Bon, ce sont des choses qui arrivent...

Là où ça devient surréaliste, c'est que, après confirmation de l'exécution des requêtes en production, Antoine vient près de moi: "Il y avait un problème dans ton fichier. (Fichier qui est, je le rappelle, le sien, sur lequel j'ai ajouté la formule Excel). Tu commençais à la ligne 2 (Note: la première était un intitulé de colonne.). Le mien commençait à la ligne 1."

Ben tiens... CTRL+C, CTRL+V de la page de formule peut-être? Et tout ça directement en production, sans demander une simulation d'exécution en préproduction par exemple...