skip to main | skip to sidebar
Code 18
Manuel du savoir-faire à l'usage des geeks et des curieux
RSS
  • Accueil
  • Le web au Québec
  • Liens
  • Twitter
  • Facebook
  • À propos

samedi 7 avril 2012

Les limites du département des miracles

Publié par Infinite Loop, à 09 h 57 1 commentaire

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

1 réponse à "Les limites du département des miracles"

  1. Anonyme a dit...
    16 avril 2012 à 08 h 10

    Dans ce genre de cas, il suffit de dire "oui oui", et de laisser le projet s'effondrer.
    En tant que directeur technique, j'ai toujours émis un avis écrit. Si malgré tout, les managers désirent passer outre, je leur en laisse le choix.
    Rien ne vaut une bonne tarte dans la tronche pour apprendre une leçon.


Publier un commentaire

Message plus récent Messages plus anciens Accueil
S'abonner à : Publier des commentaires (Atom)
    Suivre @code18 sur Twitter

    Catégories

    • Apache (21)
    • Citations (167)
    • Club Vidéo (24)
    • Coffre à outils (56)
    • CSS (8)
    • Curiosités (117)
    • Design Pattern (2)
    • Drupal (8)
    • Easter Eggs (22)
    • Extensions Firefox (20)
    • GIMP (7)
    • Histoire (21)
    • HTML (32)
    • Humour (57)
    • Intégration (34)
    • iPod (12)
    • JavaScript (110)
    • Jeu de combat (6)
    • Le coin du geek (128)
    • Liens (12)
    • Linux (56)
    • Livres (78)
    • Lois et principes (46)
    • Marché des saveurs (26)
    • Mathématique (18)
    • Mobile (5)
    • Montréal (32)
    • Musique (112)
    • Pancartes et écriteaux (16)
    • Perl (8)
    • Pérou (1)
    • PHP (130)
    • PostgreSQL (44)
    • Programmation (105)
    • Saviez-vous que (55)
    • Sécurité (22)
    • SEO (5)
    • SQL Server (22)
    • Vieilles publicités (6)
    • Virtualisation (8)
    • Voyages (1)
    • Zend Framework (26)

    Divers

    Archives

    • ►  2015 (6)
      • ►  août 2015 (1)
      • ►  juillet 2015 (1)
      • ►  février 2015 (3)
      • ►  janvier 2015 (1)
    • ►  2014 (8)
      • ►  décembre 2014 (1)
      • ►  novembre 2014 (1)
      • ►  octobre 2014 (1)
      • ►  août 2014 (2)
      • ►  juillet 2014 (2)
      • ►  janvier 2014 (1)
    • ►  2013 (53)
      • ►  décembre 2013 (2)
      • ►  novembre 2013 (1)
      • ►  octobre 2013 (3)
      • ►  septembre 2013 (2)
      • ►  août 2013 (5)
      • ►  juillet 2013 (3)
      • ►  juin 2013 (5)
      • ►  mai 2013 (3)
      • ►  avril 2013 (7)
      • ►  mars 2013 (7)
      • ►  février 2013 (11)
      • ►  janvier 2013 (4)
    • ▼  2012 (105)
      • ►  décembre 2012 (8)
      • ►  novembre 2012 (5)
      • ►  octobre 2012 (4)
      • ►  septembre 2012 (1)
      • ►  août 2012 (8)
      • ►  juillet 2012 (7)
      • ►  juin 2012 (7)
      • ►  mai 2012 (10)
      • ▼  avril 2012 (13)
        • Diagramme d'accords de guitare en canvas HTML5
        • Progresser, c'est ralentir pour mieux avancer
        • Citation no. 150 sur les erreurs
        • Initiation à la cacopédie et l'anti-savoir
        • Itérateur infini en PHP
        • En veux-tu une froide ?
        • À Montréal, il vaut mieux louer un appartement que...
        • La logique du programmeur mise à l'épreuve
        • L'approche Zen de la guitare
        • Citation no. 149 sur l'alcool
        • Les limites du département des miracles
        • Design pattern Strategy expliqué par Dexter
        • Compilation 2012 de 20+ poisson d'avril
      • ►  mars 2012 (15)
      • ►  février 2012 (15)
      • ►  janvier 2012 (12)
    • ►  2011 (146)
      • ►  décembre 2011 (14)
      • ►  novembre 2011 (11)
      • ►  octobre 2011 (12)
      • ►  septembre 2011 (13)
      • ►  août 2011 (15)
      • ►  juillet 2011 (17)
      • ►  juin 2011 (18)
      • ►  mai 2011 (15)
      • ►  avril 2011 (9)
      • ►  mars 2011 (7)
      • ►  février 2011 (3)
      • ►  janvier 2011 (12)
    • ►  2010 (398)
      • ►  décembre 2010 (29)
      • ►  novembre 2010 (28)
      • ►  octobre 2010 (32)
      • ►  septembre 2010 (34)
      • ►  août 2010 (22)
      • ►  juillet 2010 (35)
      • ►  juin 2010 (42)
      • ►  mai 2010 (36)
      • ►  avril 2010 (37)
      • ►  mars 2010 (34)
      • ►  février 2010 (32)
      • ►  janvier 2010 (37)
    • ►  2009 (430)
      • ►  décembre 2009 (32)
      • ►  novembre 2009 (34)
      • ►  octobre 2009 (33)
      • ►  septembre 2009 (37)
      • ►  août 2009 (37)
      • ►  juillet 2009 (39)
      • ►  juin 2009 (38)
      • ►  mai 2009 (37)
      • ►  avril 2009 (35)
      • ►  mars 2009 (37)
      • ►  février 2009 (32)
      • ►  janvier 2009 (39)
    • ►  2008 (84)
      • ►  décembre 2008 (34)
      • ►  novembre 2008 (39)
      • ►  octobre 2008 (11)

    Abonnés

Copyright © All Rights Reserved. Code 18 | Converted into Blogger Templates by Theme Craft