Pour la plupart de mes collègues, M. K était juste un excentrique. C’était notamment ce que pensait Baptiste, mon ancien chef de projet. Voici comment il fit sa connaissance.

Baptiste avait recruté un nouveau développeur afin de démarrer une refonte avec de meilleures chances de tenir les délais, et il le tenait en grande estime:

- Il faudrait que tu voies ce développeur à l’oeuvre, il est génial. Il est entré dans le code existant sans aucun problème. Il a un écran sur lequel il lit ce code, et simultanément sur un autre écran, il produit la v2.
- Impressionnant. Et ça marche ?
- Du feu de Dieu. Et il connaît l’outil de développement bien mieux que les gars que j’ai envoyé en formation cet été.

Quelques semaines plus tard, je croisais Baptiste dans l’ascenseur:
- Alors ce projet ? Et ton développeur, toujours aussi génial ?
– Génial, mais peut être un peu tête en l’air. Disons qu’il reste quelques bugs dans le programme. La recette a démarré lundi, et ça se passe plutôt mal.
– A ce point là ?
– Le Maître d’Ouvrage l’a dans le collimateur –c’est Jean-Pierre, tu connais le personnage. Hier en comité il déclaré: « On perd du temps, là ». Le pire, c’est que mon développeur l’a pris de haut, figure-toi.
– C’est à dire ?
– Il lui a répondu, comme ça: « Je peux ne pas corriger les problèmes, si vous voulez ! ». J’hésitais à le faire venir en comité, mais là, je suis fixé, c’est la dernière fois.
– Qu’est-ce qu’a répondu JiPé ?
– Il a respiré un grand coup. Puis il a dit que non, qu’il fallait les corriger, que c’était inévitable.
– OK.
– Puis il a ajouté: « Mais on est mis devant le fait accompli. Notre client paye pour des fonctionnalités, pas pour des corrections de bugs! »
– Je vois. Qu’est-ce que tu vas faire ?
– Bonne question. Je suis déjà en dépassement de budget. Et on ne peut pas laisser le programme en l’état.

C’est alors que je m’entendis proposer à Baptiste :
– Qu’est-ce que tu dirais de demander son avis à M. K ?
(Lire la suite…)

Pendant une longue période je n’eus que très peu d’occasions de rencontrer M. K mais j’entendais régulièrement parler de lui. Il était parfois difficile de séparer l’information de l’affabulation, car les rumeurs allaient bon train à son propos, pas tant sur sa personne d’ailleurs, mais sur la méthode qu’il adoptait avec les équipes qu’il rencontrait.

Aussi lorsque Bert, un ancien collègue avec qui je déjeunais de temps en temps, me parla d’un nouveau venu bizarre à l’étage où il travaillait, je lui demandai immédiatement s’il s’agissait de M. K:
(Lire la suite…)

J’eus l’occasion de rencontrer à nouveau M. K. dans des circonstances différentes de la première fois. Et bien qu’il n’eut guère l’occasion de l’expliquer, j’en appris plus sur sa philosophie.

Nous participions tous les deux au comité de pilotage hebdomadaire réunissant tous les chefs de projets du département. M. K. n’était pas un chef de projet, et je ne sais pas à quel titre précisément il participait au comité. En ce qui me concerne, je remplaçais mon responsable, alors en congés prolongés pour raison de santé.

M. K parlait très peu durant ces réunions, et il restait impassible, ce qui tenait pour moi de l’exploit. Le Chef de Département semblait ne pas beaucoup l’apprécier, et ne s’adressait jamais à lui. Lors d’un comité, il le prit tout de même à partie, à propos d’un indicateur sur un projet très critique.
(Lire la suite…)

C’est le bruit de mon poing frappant la table qui attira l’attention de M. K. Je fus surpris et gêné de le voir entrer dans l’open space, car à cette heure tardive je me croyais seul depuis longtemps.

Il me demanda d’une voix posée:
- Tout va bien ?

Tout n’allait pas bien. Pour la quinzième fois, la longue et fastidieuse manip de création d’un abonnement se soldait par un plantage : alias inconnu: alias1. Nous avions commencé le matin même une action corrective et l’avions terminée vers 17 heures. A 18 heures l’application était à nouveau prête, mais j’avais eu la mauvaise idée d’emprunter pour mon dernier test un chemin différent dans l’IHM. Clairement, notre action correctrice avait amené une régression dans ce module.
- C’est juste une méthode un peu récalcitrante…
- Je peux peut être aider ? Parfois, un regard extérieur..
(Lire la suite…)

Un des avantages souvent noté dans les langages « dynamiques » de la lignée de perl : python, ruby, groovy, etc. est la notion de fermeture. Qu’est-ce qu’une fermeture et à quoi cela sert-il ? Essayons cette définition (issue de ce post très intéressant de Neal Gafter, qui cherche à les introduire dans Java : a definition of closures ) :

Une fermeture est une fonction qui capture les liaisons à des variables libres dans son contexte lexical.

C’est une définition assez ingrate, mais plutôt que de tourner autour indéfiniment à la recherche d’une meilleure abstraction, prenons trois exemples, illustrant trois usages possibles des fermetures:

(Lire la suite…)

Le texte suivant est extrait du livre « Une Politique pour le Système d’Information – Descartes – Wittgenstein- (XLM) » publié par OCTO Technology :

Apparue il y a quelques années, la gouvernance du SI est un emprunt à la gouvernance d’entreprise qui définissait un modèle de communication entre salariés, dirigeants, actionnaires et régulateurs. Appliquée à cette échelle de communication, la gouvernance d’entreprise agit sur des processus rares et concernant peu d’individus: communication entre dirigeants et représentants des salariés, ou entre dirigeants et représentants des actionnaires, de l’intérêt national ou supranational. Elle se satisfait donc très bien d’outils de reporting (finances, social, environnemental, clients, produits) pour accompagner cette démarche organisationnelle.

(Lire la suite…)