Les limites du département des miracles

Ces temps-ci au boulot, j'ai l'impression de passer du temps interminable à optimiser une application web victime de son succès. Conçue au départ comme un prototype, elle a rapidement trouvé son chemin vers la production avec environ 10 fois plus d'utilisateurs actifs qu'on avait prévu initialement. Et ça augmente constamment. Sans surprise, le scaling était affreux mais par chance on y a remédié dans les derniers mois, ce qui, aux dires du patron, a sauvé le projet. Il ne reste que quelques ajustements à paufiner ici et là.

En parallèle, l'ajout de fonctionnalités demandées par les clients est devenu monnaie courante car tous ont des besoins spécifiques. Le problème, c'est quand le chargé de projet dit oui à tout sous prétexte que le client a toujours raison. Pire, il les envoie en production sans même demander l'avis technique de l'équipe et les promet pour hier. Ai-je déjà dit qu'il ne faut pas laisser le chaos l'emporter ?

Si j'envoie à Google une suggestion d'amélioration par rapport à Gmail, il est fort à parier que leur équipe de développement y réfléchisse avant même de penser à implémenter en panique la fonctionnalité manquante de peur de perdre un client. Non, elle attend sagement de voir si la tendance justifie son ajout, pour le bien de la majorité. Nous ne sommes pas Google, n'avons ni ses ressources ni sa base d'utilisateurs. En affaires, chaque client compte. C'est vrai, mais ce n'est pas une raison pour travailler en cabochon. Ce n'est pas un luxe de vérifier la faisabilité et l'utilité de la demande.

La vérité, c'est que lorsque ce chargé de projet ouvre la boîte à suggestions, il a le réflexe de dire oui à tout, avant même de lire ce qui est inscrit sur le papier pour voir si ça a du sens. Tentez l'expérience et allez au concessionnaire automobile puis demandez au vendeur si vous pouvez ajouter au modèle de base l'option sous-marin, lance-missiles et invisibilité. Les changements dans la physionomie de son visage devraient suffire comme réponse.

Voilà, lui il dit oui à ces demandes farfelues. Et il insiste pour facturer le prix de base sans considérer les coûts de recherche et développement nécessaires à l'invention de ces technologies. Il a le beau rôle de pouvoir satisfaire le client mais quand il agit de la sorte, il travaille systématiquement contre les intérêts de notre entreprise et chaque fois se met à dos des membres de l'équipe. Pour lui, ça doit être fait, le client le veut, arrangez-vous pour qu'il l'ait. Ah oui j'oubliais : c'est urgent, allez, au travail.

Le hic, c'est qu'on a un historique passé qui prouve qu'on peut faire des miracles dans certaines situations pour sauver le cul d'un supérieur qui s'est mis les pieds dans les plats. En faire régulièrement, ça devient la norme donc dans la tête de certains, rien n'est impossible. Il suffit de mettre la pression nécessaire et tous les désirs se réaliseront.

C'est un pari risqué car comme le magicien devant un spectateur, on donne la perception d'une chose en sachant très bien qu'on cache une astuce que le spectateur n'a pas besoin de comprendre. Faire disparaître un objet pour vrai, scientifiquement parlant, est différent de préparer un trucage qui en donne l'illusion. En programmation, les miracles sont atteints à l'aide de tweaks, patches, tours de passe-passes qui font disparaître un problème à l'aide d'une pratique occulte dans le code sans nécessairement respecter les règles de l'art. Et il faut être bon joueur pour accepter que l'illusion n'est qu'un truc pour arriver à nos fins.

En informatique, le miracle est l'exception : on ne peut pas s'attendre à le croiser à chaque coin de rue. C'est une question de bonne fortune lorsqu'il est sur notre chemin. Comme la lampe contenant le génie d'Aladin, le nombre de souhaits donnant droit à des miracles est disponible en quantités limitées. Il y a de ces moments où le miracle est tout simplement impossible à atteindre. Impossible dans la mesure où on n'a ni temps, ni ressources pour réaliser la demande adéquatement et qu'on ne veut pas nous les accorder. Parce que pratiquement tout est faisable mais il faut être prêt à en accepter le coût.

La semaine dernière, j'ai pris la peine de le mettre en garde face à une demande qui s'avérerait catastrophique pour l'application et qui du coup, ruinerait toutes les améliorations de performance qu'on a réalisé ces derniers mois. On a atteint une limite technique, il n'y a rien de plus qu'on puisse faire à moins de passer des mois de développement à changer la technologie et à investir une somme d'argent considérable, ce qui n'est pas une option. Je croyais m'être fait comprendre mais quelques jours plus tard, il ignora mon avis et lança le tout en production. C'est moi qui a hérité du mandat. Je suis aller argumenter dans son bureau et je me suis fait répondre ce que je ne voulais pas entendre : les désirs des clients, c'est des ordres. Et moi de répondre : moi aussi je rêve de posséder une maison qui vole, ça ne veut pas dire que la technologie existe ou que j'ai les moyens de me l'offrir.


Un jour, il ne pourra plus pousser sa chance et se heurtera contre un mur. À quoi ça sert de donner un avis technique et d'énumérer les conséquences s'ils sont ignorés à la fin ? Il suffit d'accepter qu'il y a des limites, qu'on peut les repousser par défi mais qu'il y en existera toujours, que ce soit sur le plan technologique ou humain. On ne peut pas travailler 25 heures par jour. Un sprinteur ne peut courir le 100 mètres en 3 secondes. L'haltérophile ne pourra jamais soulever sur ses épaules une charge de 3 tonnes sans craquer ses os. L'informatique aussi a ses limites, elles sont seulement moins concrètes.

Tags: Lois et principes, Programmation