Mon arrivée chez un éditeur logiciel

Dans une ancienne vie, j’ai travaillé pour un éditeur logiciel. Il est temps de vous raconter le début de cet aventure.

Note : je parle d’un temps ancien, les choses ont bien changées depuis.

A cette époque, je travaille dans une SSII et je cherche depuis quelques mois à changer de poste. Comme on dit dans les milieux autorisés, je suis en recherche active. Mes dirigeants veulent que je me casse mais sans me licencier. Parce qu’en plus d’être cons, ce sont aussi des pingres. Bref, je cherche. Cela fait des années que j’ai abandonné l’idée de me remettre au développement logiciel, n’aimant pas les langages en vue comme PHP ou Java. Quant aux technos Microsoft, c’est hors de question. Les possibilités sont donc limitées. Je cherche donc du coté de l’admin système Unix, ou de la gestion de projet. Au cas où, je vais quand même regarder les offres Python en France : j’en trouve cinq sur Monster. Je vais répondre à quatre. La cinquième étant pour un poste de junior. Vous comprendrez à la fin pourquoi j’en parle. Pour la petite histoire, je regarde aussi les offres d’emplois US pour développeur Python : les entreprises sont la NASA, Disney, Google, ILM… Je pleure.

Parallèlement, je suis contacté par un chasseur de tête qui a vu mon profil sur Viadeo, profil que j’ai activé peu de temps avant. Ses mots clé étaient Python et Scrum (j’entends d’ici les rires de certains, private joke). Et à l’époque, il n’y avait pas beaucoup de gens avec ces mots clés sur leur CV. Bon contact au téléphone, on décide de se rencontrer. J’étais déjà à l’époque dans mon trip entreprise apprenante, qualité organisationnelle et tout le toutim. Je suis donc franco sur ce que je cherche. L’entretien se passe bien, le feeling passe, ils comprennent vite et plutôt bien (et pour en avoir rencontré une palanquée de chasseurs de tête, j’étais assez surpris). Ils me rappelleront plus tard pour me dire que la boite veut me voir.

La rencontre avec mes 2 futurs boss se passent plutôt bien. Je suis le premier candidat. On parle de développement logiciel et d’agilité. Le mot Scrum revient assez souvent dans leur bouche et j’apprendrais plus tard que c’est un bon pote du PDG, lui aussi serial-entrepreneur qui est passé à Scrum quelques temps auparavant, et qui lui a conseillé. On discute à bâton rompu sur le profil recherché : une personne qui connait bien Python puisque c’est la techno dominante, Linux, les Logiciels Libres, l’agilité et qui a une expérience en management. Et comme il y avait tout ça sur mon CV (utilisateur de Linux depuis 95, Python 99, XP 2001 et «manager» du pôle Logiciel Libre dans ma boite de l’époque), ça tombait bien.

J’apprends aussi que l’entreprise est en grande difficulté avec son nouveau développement, qui dure depuis des mois sans voir le bout du tunnel. Et pour corser le tout, la relation avec l’équipe technique est très tendue et la tension palpable. Ce qui rend le boulot très intéressant mais difficile : ce genre de souci est le reflet d’une organisation défaillante (le produit est le résultat de son organisation est une de mes phrases préférées), ce qui sous entend des problèmes organisationnels, techniques et humains à résoudre. C’est d’ailleurs la principale information que je noterais sur mon Mindmap : que se cache t’il vraiment derrière ce problème de développement ? Je sentais qu’on me disait pas tout, et d’ailleurs j’avais noté un détail qui en disait long à mes yeux : les locaux étaient constitués principalement de 2 pièces. Une petite qui contenait les commerciaux, et une grande avec les développeurs, le support, l’avant vente et l’office. Et où était exactement les développeurs ? En plein milieu de la pièce ! Aucune protection contre les allées venues, ni le bruit. Ce n’est pas comme si Tom DeMarco avait écrit dans son livre Peopleware qu’il y a une relation directe entre productivité d’un développeur et la qualité de son environnement. Livre écrit en… 1987.

J’aurais un deuxième entretien, puis rapidement une réponse positive. J’apprendrais plus tard que j’étais le plus crédible des candidats concernant l’agilité mais je ne suis pas sûr que cela soit vraiment un compliment. Je vais en fait me rendre compte en moins de six mois que je ne sais rien (la lecture de livres, aussi nombreuses soient-elles n’apportent pas d’expérience, mais juste des voies à explorer), et il me faudra trois ans pour me construire une expérience qui tienne la route. Mais ceci est une autre histoire.

Je me donne trois ans pour redresser la barre : non seulement sortir le nouveau produit mais rendre la R&D capable de livrer régulièrement des releases de qualité. Et pour moi trois ans c’est loin ! A cette époque, j’avais fait dix sociétés en sept ans (oui 10), la plupart quittée car je n’étais pas du tout adapté au modèle de pensée dominant. Faut dire que j’avais fait dix SSII, ceci explique en partie cela.

Mon poste est officiellement celui decoach R&D. Au bout de ces trois ans, je me poserai la question de mon utilité dans l’organisation. Trois ans pour redresser une société de développement au fond du gouffre était un challenge intéressant à mes yeux :).

Avant d’aller plus loin et de vous raconter mes premières semaines, je vais vous rappeler quelques points :

• C’est la 1ere fois que je travaille chez un éditeur logiciel. J’ai bien eu une toute petite expérience dans une boite qui mixait éditeur et SSII (une startup où j’étais le seul techos) mais elle faisait éditeur sur son temps libre (une SSII quoi). Et puis c’était y’a fort longtemps.

• C’est la 1ere fois que je travaille comme coach. J’ai bien une expérience livresque de l’agilité mais je ne peux pas vraiment dire que c’est une expérience terrain. J’ai bossé en SSII hein, ça ne fait pas d’agilité. Mon boulot précédent de responsable du pôle Logiciel Libre m’a donné un premier aperçu du management, mais dans un cadre SSII, cela se résume plutôt à de l’avancement de tâches.

• C’est la première fois que je travaille dans le domaine d’expertise de la société.

• Cela fait longtemps que je ne développe plus à plein temps, ayant au travers des années multiplié les expériences : responsable technique, développeur, administrateur système, administrateur sécurité, chef de projet, etc. le peu de développement effectué ces derniers années sont plutôt de l’intégration. Je n’ai pas l’expérience requise pour prendre le développement à 100% sur mes épaules, je sais donc pertinemment que je dois m’appuyer sur une équipe de développeurs.

Autant dire que je n’ai pas une grande expérience du boulot qui m’est confié et que je pars d’assez bas, mais heureusement pour moi l’environnement est assez familier. Si j’avais dû travailler sous Windows en Java en mode RUP, le problème aurait été tout autre :). Et puis j’adore apprendre, sans compter ma veille permanente dans pas mal de domaines depuis 10 ans qui peut m’aider.

Maintenant parlons de la première semaine.

Comme je pouvais en douter, c’est l’organisation dans son ensemble qui pose le plus gros souci : peu tournée vers le développement, elle se focalise sur la réussite commerciale à court terme. Le résultat s’en ressent : développement baclé, fonctionnalités peu étudiées… La disposition physique que j’évoquais plus haut était révélatrice : les commerciaux vont voir sans cesse les développeurs pour leurs demander des fonctionnalités et des corrections. Le commercial est roi et le développeur pédale. La nouvelle version est promise depuis un an déjà, les clients demandant sans cesse où en est le développement. Autre signe révélateur, les commerciaux (et le DG) rigole assez souvent du fait de «vendre du vent». Jamais su si c’était une mauvaise blague ou une putain de fierté mal placée de commercial, mais j’avais une envie de foutre des baffes.

Ces pratiques ne m’étonne pas car elles sont sous jacentes d’une certaine mentalité que je rencontrais assez fréquemment dans mes postes précédents : une incompréhension forte du développement logiciel, avec son cortège d’erreurs (profil des développeurs, absence de refactoring et des tests, manque de vision partagée, etc) et une absence de réflexion organisationnelle. Pour savoir tout ce qu’il ne faut pas faire, rien de mieux que la SSII (malheureusement, savoir ce qui ne faut pas faire n’apprend absolument pas à savoir faire, comme je l’entends trop souvent. Ôtez vous une bonne fois pour toute cette connerie de votre tête). L’équipe de développement du nouveau produit est constitué de cinq personnes. Un expérimenté qui fait du Python, un petit jeune qui fait du C, un stagiaire en alternance touche à tout, un «vieux» qui s’est reconverti au développement logiciel et le directeur R&D, à l’origine du produit. Je m’aperçois très vite du climat délétère. Les deux premiers sont en confrontation directeavec le management, en position de «combat». Ils s’amusent par exemple à les critiquer violemment en réunion R&D en sachant parfaitement qu’ils seront entendus. Attitude incompréhensible alors qu’ils pouvaient se barrer et trouver du boulot ailleurs assez facilement et gagner un bien meilleur salaire. Avec le recul, je ne comprends toujours pas. Les gens s’entêtent des fois dans des voies sans issues et préfèrent se briser sur des rochers plutôt que rebondir.

Voici une autre anecdote : Il y avait plusieurs balles dans la pièce (vous savez, ces conneries de balles soit disant déstressantes), balles qu’ils s’amusaient à s’envoyer les uns sur les autres. A plusieurs reprise, je m’en suis prise une sur la figure. Je me souviens encore me demander si j’allais pas en prendre un et lui exploser la gueule.

D’ailleurs cela n’a pas manqué, le responsable R&D et le jeune en sont presque arrivés aux mains lors d’une réunion en tête à tête. Le responsable était d’ailleurs au bout des nerfs, prenait des cachets pour dormir et on sentait bien qu’il n’allait pas tenir longtemps. je passais d’ailleurs des heures chaque jour à l’écouter, tellement il était en souffrance. Il s’est énormément investi mais s’est rendu compte qu’il détestait manager des développeurs. Il est du genre à tout prendre sur ses épaules mais c’était bien trop. Bon admin réseau, avec une réelle vision produit (qualité rare), il a échoué à créer une équipe de développement et à partager sa vision. Il avait échoué et le savait, ce qui le minait terriblement.

Le stagiaire attendait patiemment son diplôme dans 3 mois pour se barrer. Bien que stagiaire, il était la depuis des années car la société lui a payé en partie ses études supérieures et avait donc une grande connaissance de l’histoire du projet, ce qui était capital pour la réussite de ma démarche. C’était le seul à avoir cette connaissance avec le responsable R&D, et si les deux partent, je me retrouve vierge de toute connaissance du produit actuel.

Et pour corser le tout, le dernier de la liste, c’est à dire le reconverti en développeur est mauvais. J’ai voulu le tester en lui demandant de coder une petit code Python d’envoi de mail, chose qui doit prendre 30 minutes en allant vite, une heure avec la doc. En cinq jours, il n’avait pas terminé. Il n’avait même pas cherché sur PyPI (index des projets Python) qui ne connaissait d’ailleurs pas.

En ce qui concerne le produit actuellement vendu, il est tellement bancal que le stagiaire à comme boulot de faire du support toute la journée pour corriger l’application des clients (en prod donc) qui tombent en panne. Rassurant ! Je demande l’url du dépôt SVN pour voir le code, on me répond que «cela fait des mois que plus personnes ne commit dedans». Ce qui veut dire qu’il n’existe aucune trace des modifications faites en prod. Chaque client à donc sa propre version. Une sorte de code personnalisé en sommes :). J’apprends donc que nos clients sont en «3.2 quelque chose».

Pour coder, chacun à sa sonde et il n’y aucune procédure d’installation. Impossible donc de travailler sur sa machine directement ou de connaitre l’état exact du sonde. En regardant directement une sonde, le code est principalement en PHP. Mais du code PHP qui rendrait celui de PHPBB un sommet de qualité et de perfection. La plupart du HTML est rendu par des print, il y a même souvent du code PHP qui génère du JS qui génère du PHP qui génère du HTML ! Le reste est fait de scripts Python 2.3 ou 2.4 (en double voir triple exemplaires, on ne sait pas qui est vraiment utilisé). Le tout lancé et relancé en permanence par daemontools car la plupart des scripts se plantent plusieurs fois par jours. Car si le PHP était dans un état de délabrement avancé, c’était aussi le cas du code Python. Je n’arrive pas à savoir comment certaines données sont calculées. La base MySQL tombe sans arrêt, ce qui fait perdre instantanément des données. L’ergonomie est disons…l’œuvre de développeurs.Le résultat est donc un produit qui marche «on ne sait comment». Seul point positif (mais important), il est simple et accessible.

Pour faire une release, ils utilisent un outil de création d’image : ils appliquent les modifications sur une sonde puis enregistre une image. Il suffit ensuite de déployer de nouvelles sondes pour travailler. Simple certes mais faut être extrêmement vigilant et bien documenter chaque évolution. Comme cela n’est pas fait, on ne sait pas reproduire l’image en question. Ah et pour corser le tout, c’est une Debian Sarge bancale : impossible de toucher à dpkg car des paquets sont cassés.

Cerise sur le couscous, une version anglaise existe en plus de la version française. i18n me direz vous ? Que nenni ! Ils ont fait la trad à coup de sed ! Il existe donc deux bases de code, une à jour en française et une qui a un sérieux retard en anglais.

Je me rends compte que le produit est dans un tel état qu’il sera impossible de faire du substantielle évolution. Il ne me reste que le code de la nouvelle version pour me sauver d’un désastre annoncé. Cette fois ci il existe un SVN à jour, avec un répertoire par… développeur. Cela retranscrit assez bien je crois l’organisation de l’équipe : chacun chez soi et parlons nous le moins possible. Je rappelle que cette nouvelle version est développée depuis un an. Et si le code est de meilleure qualité, il est inutilisable et loin du périmêtre fonctionnelle attendu. Il y’a encore des mois de boulot.

Au bout d’une semaine, le DG et le PDG me viennent me voir pour me poser une question : «Alors, on les vire ?». «Uh?! Je viens à peine d’arriver, laissez moi le temps !». Je leur demande une semaine pour prendre une décision, même si au fond de moi je n’y crois plus trop. Une semaine plus tard, la décision est prise de virer tous les développeurs sauf le stagiaire. C’était la première fois que je prenais la décision de virer quelqu’un (même si officiellement je n’avais pas la responsabilité). Je savais que ca serait dur pour le «vieux» de retrouver du taff à son âge et sa faible connaissance et expertise. Je suis descendu au rez de chaussée et j’ai pleuré un coup. Ah, tant qu’a être dans les bonnes nouvelles, j’annonce par la même occasion que tout le code du futur produit (trois années / homme l’air de rien). est à jeté et qu’on tiendra pas longtemps avec l’actuel.

Je me retrouve donc au bout de deux semaines sans (presque) personne et sans code, à devoir reconstruire manu militari une toute nouvelle équipe afin de développer un tout nouveau produit dans un métier que je ne connais pas. Si ce n’est pas du challenge… Beaucoup de gens vous le diront, redévelopper à partir de zéro (from scratch) est le plus gros danger qu’une boite peut faire. Surtout quand c’est pour remplacer le produit qui fait 100% du chiffre d’affaire.

Vous connaissez maintenant mes deux premières semaines. Ah, et l’histoire des cinq annonces Python du début me diriez vous ? Et ben, la cinquième annonce, celle sur le développeur junior était… de ma nouvelle boite. Et plus rigolo encore, j’ai passé un entretien dans l’une des quatre autres, entretien catastrophique avec un PDG d’une extrême froideur. Ce même PDG qui viendra me demander conseil deux ans après car eux aussi avaient le même problème de livraison. Pourquoi moi ? Car lui et mon PDG se connaissaient puisque ayant fondés la société… ensemble. Rigolo non ?