Responsable des développements. Ouais, c’était un titre assez pompeux mais Jamie y était préparé. Il avait passé des années en tant que développeur et savait que c’était le bon moment pour prendre un poste de management. En plus, l’équipe qu’il allait gérer était plutôt petite et il pourrait toujours participer aux développements si nécessaire. L’offre était parfaite et ainsi, Jamie devint un manageur.
La société était un éditeur d’annuaire pour professionnel et, pendant le quart de siècle passé, avait soutraité la majorité de ses développements logiciels à une autre société de consultant. Par « Société de consultant », j’entends une société d’une personne employant un seul consultant. Et par « consultant », j’entends un bougre auquel les vingt-cinq ans d’expérience viennent de son premier et unique client, l’éditeur d’annuaire professionnel. C’était avec ce consultant que Jamie et son équipe de développeur allaient devoir traiter pour fournir aux divers services (Client, Editorial, etc) des applications.
Année après année, le consultant avait convaincu les personnes métier que sa façon de faire était la bonne. Cela, en soi, était un tour de force plutôt impressionnant. Par exemple, son application de facturation ne pouvait jamais avoir plus de trois éléments dans la facture ; ce qui menait à des situations intéressantes pour le département client qui, avec le temps, avait appris à faire avec.
L’un des premiers actes de Jamie en tant que manageur fut de superviser le déploiement et la phase de test de la nouvelle application de gestion de contenu du consultant pour le département éditorial. C’est cela : déployer et tester. C’était apparemment la bonne façon de faire les choses.
Le déploiement était laborieux : le consultant faisait le tour de tous les utilisateurs avec une clé USB et copiait l’application directement sur le PC de chacun. Pas d’ "installation réseau ", simplement une copie du répertoire /Bin du consultant contenant du code compilé.
La stratégie de test était un peu plus intéressante. Le consultant s’asseyait sur un bureau près du bout de la salle d’où il était physiquement capable de voir tous les utilisateurs. Avec une voix portante, le consultant demandait à tout le monde de double cliquer sur le raccourci du bureau et de lever la main s’ils rencontraient un problème. Chaque utilisateur leva la main : Il s'est avéré que personne n’était authentifié pour se connecter à l’application.
Il fallut quelques minutes au consultant pour comprendre le problème et il porta le blâme immédiatement sur Jamie. « Hum, à quel moment chacun a-t-il changé son nom d’ordinateur ? »
N’ayant aucune idée de ce dont il parlait, Jamie demanda à l’équipe réseau. Ils expliquèrent que, trois années auparavant, ils avaient changé les noms de machines nommées par les utilisateurs (CHRIS-ADAMS), par une règle de nommage plus standardisée (WKST-ED-09). Il s’avérait que le système de gestion de contenu du consultant utilisait les identifiants de machines dans la base de données pour l’authentification.
Avant que Jamie n’ait eu une chance d’expliquer le problème, le consultant était déjà en train de travailler sur sa « résolution ». Il avait une liste de toutes les id de machines et ajouta une colonne supplémentaire à la table utilisateur, ainsi, il pouvait déterminer quel utilisateur était connecté. Après un autre tour de déploiement, le consultant donna de nouveau l’ordre de « double clic » et, de nouveau, toutes les mains se levèrent : personne ne pouvait voir de données.
Le problème cette fois venait de la « base locale » qui ne fonctionnait pas. L’application fonctionnait en répliquant la base de données de production sur une base de données sur le poste utilisateur et fusionnait la base locale avec celle de production lorsque l’utilisateur fermait l’application. Le code du consultant nécessitait non seulement que les utilisateurs soient administrateurs de leur machine mais aussi du serveur hébergeant la base de données.
Ce fut une négociation serrée mais les administrateurs réseau, sous la pression de tous, donnèrent finalement les droits administrateurs nécessaires. Un autre tour de test commença et cette fois, après avoir dit à tout le monde de « double cliquer », aucune main ne fut levée. L’application fonctionnait.
Quelques heures et plusieurs « mains levées » plus tard, le consultant réalisa qu’il y avait un petit problème : deux utilisateurs pouvaient modifier le même enregistrement. Ceci causait un conflit quand les bases locales se synchronisaient à la base de production. Avant que Jamie puisse dire « Réplication concurrente optimiste », le consultant développait déjà sa mise à jour : Les enregistrements seraient répartis selon les utilisateurs, ainsi, un éditeur ne verrait que les enregistrements allant de « A à C », un autre ne verrait que de « D à F » et ainsi de suite.
Bien que l’équipe éditoriale ne fut pas très à l’aise à propos de ce changement, ils comprirent que c’était la bonne chose à faire et acceptèrent de modifier leur processus métier.
C'est à ce moment que Jamie réalisa que ses jours étaient comptés, et qu'il n’y avait tout simplement aucune possibilité qu’il puisse rivaliser avec le consultant. Cela expliqua aussi pourquoi la société avait eu tant de mal à conserver un responsable du développement. Il remit sa démission, trouva un autre emploi, et ainsi, Jamie retourna au développement.
