Contrairement aux développeurs privilégiés, on n'a pas tous la chance de développer dans un "grand bureau privé climatisé". Dans mon ancienne société, les développeurs arrivaient chaque matin en se demandant comment ils allaient trouver un siège pour la journée ou comment se procurer un câble réseau pour pouvoir travailler. On est certes pas tous logés à la même enseigne, cependant, peu d'entre nous peuvent se comparer à ce qu'a vécu Stéphane récemment :

"On ma demandé d'aller faire une intervention dans une petite société pour corriger quelques bugs sur leur système de gestion. Apparemment, la personne qui était en charge de la maintenance du logiciel venait de démissionner. "

Mot de passe oublié? Pas de soucis, vous pouvez toujours utiliser le mot de passe d'invitation que l'on vous a envoyé lors de la création de votre compte !

Envie d'essayer avec un autre compte? Pas de soucis, vous pouvez utiliser ce même mot de passe pour vous connecter sous chaque compte !

"Barnier ne peut pas se connecter," lança le responsable de David, "Il faut réparer ça. De suite !"

Quelle meilleure façon de commencer une semaine? Quand Barnier ne pouvait pas se connecter, cela sous-entendait qu'il ne pouvait pas exécuter ses rapports d'activité. Et ça sous-entendait aussi que la société toute entière devait stopper toute activité et se concentrer sur son nouvel objectif archi prioritaire : les rapports de Barnier.

Comme il était le plus expérimenté de son groupe lorsque l'on parlait de C#, c'est souvent à Yakir que les développeurs posaient leurs questions. Récemment, un de ses collègues, James, lui demanda la meilleure façon de stocker des centaines d'objets en mémoire. Yakir lui répondit : "Cela dépend de ce que tu souhaites en faire. Si tu veux l'utiliser via un index, le plus simple c'est l'Arraylist. Par contre, si tu veux utiliser le système de clé/valeur, alors prend une Hashtable."

Les besoins de l'application de James semblaient mieux coller avec l'utilisation d'une Hashtable, il décida donc de l'implémenter. Quelques heures plus tard, il revint vers Yakir : "Ton système de Hashtable ne marche pas super" expliqua James, "Tu ne connais pas quelque chose de plus efficace?".

Savoir rejetter une faute sur un tiers est un art puissant qui nécessite d'être utilisé avec agilité. Dans certains cas la situation rend la chose plutôt simple. On peut citer le classique "C'est à cause du prestataire mais lui en parle pas ça le mettrait mal à l'aise", où encore le "Ha ça .... encore une peau de banane que X a laissé derrière lui" (remplacez le X par un collègue parti, vous noterez le bonus x2 lorsque le collègue est prestataire). Certains font preuve d'une imagination incroyable pour réussir à se sortir des pires situations, parfois ça passe, parfois pas. La règle d'or est pourtant simple : s'assurer de bien cerner les limites des connaissances de son interlocuteur, et lui envoyer un argument hors limite avec un aplomb sans faille. Malheureusement pour eux, les éditeurs du logiciel que Rick utilisait n'ont pas fixé cette limite bien loin...

Depuis plusieurs jours, Rick était en conflit avec un éditeur de logiciel. Le système de Rick était sensé communiquer avec le logiciel de l'éditeur en utilisant des fichiers XML. Problème, les fichiers en provenance du système éditeur revenaient dans un format XML incorrect. Rick envoya donc un message au contact technique ("Terry") signalant que les données retournées n'étaient pas valides. Terry lui répondit qu'il allait analyser le fichier en question.

C'est la crise ! Développeurs, augmentez vos lignes de code pour conserver votre job ! Plus le code est long et inutile, plus vous aurez de jours de travail nécessaire pour le maintenir. Et puis, si ça a été dur à développer, il faut bien que ça soit dur à relire non ? Le développeur qui a produit le code que Quentin doit aujourd'hui maintenir avait certainement pressenti la crise arriver...

Depuis maintenant 3 mois, j'ai le "plaisir" de travailler sur la remise à flots d'un projet Java/J2EE. Les délais ont été explosés, les soucis de performances sont constants et la base de code fait peur à voir. Duplication de code, syndrome NIH, métriques qui crèvent le plafond, sans parler de tout le code écrit au mépris des plus simples règles de programmation.

Je suis sûr que nous avons tous des histoires de projets cauchemardesques que nous héritons de nos clients. Que ce soit un programme critique écrit (en JavaScript) par le cousin de la secrétaire, ou un projet où on laisse les utilisateurs faire eux-mêmes l'analyse de leur outil de gestion de production. Jakeypoo nous fait partager un de ses pires cauchemars :

Imaginez ma surprise quand je suis tombé sur un de ces projets avec ses pages ASP bien écrites et commentées : Je me suis dit que ça allait être facile.

Marcel est administrateur système responsable d'un groupe de bibliothèques. Concrètement cela veut dire que c'est lui qui connait les réponses aux questions "Ce clavier est-il bien branché" et "Pourquoi l'écran s'éteint-il quand je touche ce bouton?".

Mars dernier l'une des bibliothèque dont il a la charge à eu un sérieux problème. Chaque bibliothèque possède un serveur principal ou sont stoquées toutes ses transactions : qui à emprunté tel livre, qui n'a pas payé son abonnement, etc. Le serveur en question était éteint lorsque Marc arriva un matin et il fut incapable de le faire démarrer. Heureusement, le serveur était sauvegardé chaque nuit, Marcel demanda donc à un de ses collègues d'aller chercher la bande de sauvegarde, pendant que lui essaierai de réparer le système.

Mickael qui travaille dans un projet d'e-commerce est tombé il y a quelque jours sur un morceau de code pas banal...

la petite dernière, trouvée dans le source d'un presta... the names have been changed to protect the incompetent (remplacez les xxx par l'adresse mail du développeur).