Les pompiers pyromanes

L’un des profils de collaborateur les plus difficiles à manager sont les « pompiers pyromanes ». Voyons à quoi on reconnait un tel profil, les dangers qu’ils peuvent représenter et les solutions qui existent pour les gérer.

C’est quoi un pompier pyromane ?

Peut-être que vous vous êtes déjà retrouvés dans cette situation. Vous assignez des tâches à vos développeurs (ou ils se les répartissent eux-mêmes dans le cas d’une équipe auto-organisée) ; ces tâches sont souvent en deux groupes : les nouveaux développements d’un côté, et les débuggages ou micro-évolutions de l’autre.

Pour schématiser, les nouveaux développements prennent du temps, plusieurs jours voire plusieurs semaines, alors que les débuggages ont des durées qui se comptent en heures la plupart du temps. L’investissement nécessaire est donc très différent, que ce soit au niveau de la réflexion technique à mener que dans la durée de concentration à avoir sur son travail.

Un pompier pyromane, c’est avant tout un « pompier », c’est-à-dire quelqu’un qui se sent bien dans le rôle de sauveur. A chaque fois qu’il résout un bug, il est remercié chaudement par la ou les personnes qui étaient impactées au quotidien. Plus il est rapide dans la résolution de problèmes, plus sa valeur semble augmenter aux yeux de ses collègues. C’est normal, il leur facilite la vie, il résout leurs soucis.

Au fur et à mesure, ce genre de personne va vouloir de moins en moins travailler sur de nouveaux développements. Après tout, pourquoi vouloir bosser dans l’ombre pendant plusieurs jours, à se casser la tête à résoudre des enjeux techniquement complexes ? Quand un nouveau projet est mis en production, les développeurs qui ont travaillé dessus sont rarement acclamés ; ils reçoivent peut-être des félicitations par leur hiérarchie, mais pour les collègues des autres services c’est au final assez peu visible. Dans le pire des cas, c’est même une source de nouveaux bugs. C’est tellement mieux d’être vu comme celui qui corrige les bugs plutôt que d’être celui qui les crée, non ? Continuer la lecture de « Les pompiers pyromanes »

Les spécifications à problème (3) Spécifications qui arrivent après le développement.

Ce billet est le dernier d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Les deux précédents concernaient :

En image

Continuer la lecture de « Les spécifications à problème (3) Spécifications qui arrivent après le développement. »

Les spécifications à problème (2) Spécifications qui changent en cours de développement

Ce billet fait partie d’une série de trois articles consacrés aux spécifications et à leurs problèmes. Le précédent portait sur les développements réalisés sans spécification. Je vous invite à le lire rapidement pour comprendre le contexte. Le troisième article porte sur les spécifications qui arrivent après le développement.

En image

Continuer la lecture de « Les spécifications à problème (2) Spécifications qui changent en cours de développement »

Les spécifications à problème (1) Pas de spécification

Il existe 3 grands types de problèmes avec les spécifications. Il y a quelques mois, j’ai préparé une présentation pour expliquer notre nouvelle organisation dans mon entreprise. Dans cette présentation, j’abordais les spécifications, en tentant d’expliquer les conséquences négatives qu’il peut y avoir lorsqu’elles ne sont pas préparées correctement.

Pour rendre mon propos immédiatement compréhensible, j’ai fait un parallèle avec l’architecture «classique», qui est souvent utilisée pour imager l’architecture informatique. Soyez indulgents quant à la qualité des dessins, ça a été fait avec OpenOffice Impress, qui n’est pas vraiment idéal pour ça (ni aidé par mes talents).

Je vous invite aussi à lire les deux articles suivants de cette série :

En image

Continuer la lecture de « Les spécifications à problème (1) Pas de spécification »

Idée d’entreprise : Plate-forme logicielle

Dans la série des idées de création d’entreprise, voici quelque chose auquel je pense depuis assez longtemps.
Contrairement aux cas précédents, pour lesquels où il s’agissait d’idées de business, là je suis parti d’un besoin technique et j’ai réfléchi à la manière d’en faire une entreprise viable.

De quoi s’agit-il ?

De par mon travail et mes goûts personnels, j’ai toujours préféré écrire des logiciels avec une interface web. Je connais aussi bien les technologies «front» (HTML/CSS/Javascript) que le développement côté serveur (et ma préférence va vers le PHP, comme de nombreuses autres personnes).

Il m’est arrivé à plusieurs reprises de faire des applications prévues pour s’exécuter en local sur un ordinateur. Je parle d’interface «lourde», par opposition au «client léger» reposant sur une interface web. Quoi de plus normal de chercher alors à utiliser des technologies qui se rapprochent de ce que j’ai l’habitude d’utiliser. Dans le genre, il en existe deux que j’ai pratiquées en profondeur : XUL et PHP-GTK. Chacune d’elles possède des avantages et des inconvénients :

  • XUL est la technologie créée par Mozilla pour servir de moteur à Firefox et Thunderbird. Elle permet de créer des interfaces très puissantes avec du XML et du Javascript. Sa grande force est de permettre le mélange de XUL (dérivé du XML) pour décrire l’interface avec du CSS pour en définir le style. On peut même y mettre du HTML, c’est assez pratique. L’inconvénient, c’est que le Javascript est un langage qui se prête mal − à mon sens − à la création d’applications un tant soit peu complexes, à cause de son modèle objet très incomplet et au manque de fonctionnalités dans le langage. Mozilla propose d’ailleurs tout un tas d’extensions spécifiques, mais qui sont très verbeuses à utiliser ; rien que la lecture d’un fichier sur le disque local nécessite au moins 8 lignes de code abscons impossible à retenir.
  • PHP-GTK, pour sa part, est un «binding» de la bibliothèque graphique GTK+ avec l’interpréteur PHP. Il permet de créer des logiciels qui s’exécutent avec une interface très valable mais difficile à styliser. Il est possible de composer l’interface en XML (grâce à Glade). Le gros avantage, c’est de pouvoir utiliser toute la bibliothèque native de PHP, qui est très complète. L’inconvénient, c’est que le développement d’interfaces graphiques en PHP est plus pénible que le développement d’applications web côté serveur.

Malheureusement, aucune de ces deux solutions n’a réussi à s’imposer. En fait, elles n’ont même pas réussi à se faire la moindre place réelle dans le paysage informatique actuel. J’exagère un peu, on trouve une poignée d’applications d’envergure basées sur XUL ; mais sincèrement, ces deux plate-formes ne viennent à l’esprit de personne lorsqu’il s’agit de créer un logiciel avec une interface graphique native.

À mes yeux, cela s’explique assez facilement :

  1. Quel est le propos de ces technologies ? Offrir aux développeurs web la possibilité de développer des programmes «non web» en capitalisant sur leurs connaissances et leurs compétences.
  2. Pour cela a-t-il échoué ? Parce que les compétences réclamées par le XUL (XML/CSS/Javascript) ne permettent pas de développer facilement du code métier, et que personne n’a d’expérience dans la création d’interfaces graphiques en PHP (donc personne n’a envie de faire des interface graphiques en PHP).

Comment s’y prendre ?

Pour moi, la solution est simple : Il faut créer une plate-forme logicielle qui duplique l’esprit des développements web. C’est-à-dire qu’il faut pouvoir utiliser des technologies différentes entre la partie interface (HTML/CSS/Javascript) et la partie «traitements» (PHP).

Continuer la lecture de « Idée d’entreprise : Plate-forme logicielle »

À propos du refactoring

Je vous ai déjà parlé de refactorisation. Voici un retour d’expérience un peu atypique.

Ces derniers mois, nous avons procédé dans mon entreprise à un gros chantier de réécriture de code. Ce chantier a été lancé durant l’été, et s’est déroulé de septembre à décembre, avec une mise en production à Noël. J’ai voulu en parler sur le blog pendant qu’on bossait dessus, mais je me suis révisé, préférant attendre la fin de ce travail pour pouvoir faire un vrai retour sur expérience.

Les raisons initiales

Pour commencer, je voudrais vous parler du «combat interne» qui s’est livré dans mon crâne. Parce que je garde toujours à l’esprit une règle importante : Améliorer par évolutions et pas par révolution

Cette règle est un garde-fou salvateur. Quand on rencontre des difficultés pour faire évoluer un développement, il est souvent très tentant de tout effacer et de tout recommencer. Mais si cela est envisageable pour un projet personnel, c’est plus difficile à concilier avec les nécessités économiques d’une entreprise. Néanmoins, nous sommes quand même repartis d’une feuille quasi blanche. Comment est-ce arrivé ?

Plusieurs événements se sont additionnés les uns aux autres, sur un intervalle de temps d’à peine quelques semaines :

  • Nous avons rencontré des problèmes de performance sur les sites que nous éditons. Plusieurs passes d’optimisation avaient été nécessaires pour atteindre un niveau satisfaisant, mais cela restait inférieur à ce que j’estimais “normal”. Ces soucis provenaient pour la plupart de requêtes SQL mal fichues ; mais après avoir les avoir optimisées, nous nous sommes rendu compte que sur certains aspects nous avions atteint les limites de notre modèle.
  • Nous avions alors du code un peu ancien, qui avait vécu plusieurs évolutions, et qui avait survécu à plusieurs changements dans les choix fonctionnels. Malgré plusieurs refactorisations, le code contenait toujours des scories qui nuisaient à ses performances, mais surtout qui le rendaient de plus en plus difficile à maintenir et à faire évoluer.
  • De nouvelles fonctionnalités devaient être développées, certaines imposant des modifications du modèle de données, et non pas seulement des ajouts. À cela s’ajoutait une refonte graphique des sites, qui impliquait de toute manière de réécrire les «points de contact» entre le code pur et les templates de pages.

Chacune de ces raisons nous poussait à envisager une réécriture partielle de notre code.

J’ai lu un jour un article qui parlait des spécificités des développements open-source. Il contenait un conseil assez intéressant : Si vous voulez écrire un logiciel de bonne qualité − hors de toute notion de rentabilité − il vous suffit de l’écrire, puis de jeter le code et de tout réécrire. Le fait d’avoir été confronté aux problèmes une première fois fait que vous saurez la direction à prendre pour votre développement, en évitant les errements par lesquels vous serez passé la première fois.

Les raisons supplémentaires

Pendant la phase d’analyse technique, pendant laquelle nous réfléchissions aux différents moyens nous permettant d’atteindre nos objectifs, nous avons fini par converger vers une solution technique hybride. Nous avons choisi de mélanger l’utilisation d’une base de données relationnelle (MySQL) et d’une base de données non relationnelle (FineDB, développée en interne). Le but est de concilier le meilleur des 2 solutions : Continuer la lecture de « À propos du refactoring »

Les premiers enseignements de Rework

J’ai déjà parlé plusieurs fois de l’entreprise 37signals, de ses logiciels de gestion de documentation et de projet, et de sa méthode Getting Real. Actuellement, ses membres travaillent au successeur de leur livre, dont le nom sera Rework. Ils ont présenté quelques bribes d’information sur le livre, et je me suis arrêté sur le quatrième de couverture :

Je trouve que le texte qui s’y trouve est très intéressant, un brin controverse, et mérite qu’on s’y attarde. Voici une traduction très libre de son contenu, et ce que j’en pense.

“Dès que possible” est un poison

Il est vrai qu’en entreprise, on rencontre bien souvent ce genre de situation : On essaye de se mettre d’accord sur la spécification d’une nouvelle fonctionnalité, et quand vient le moment d’en définir la date de livraison, on se voit répondre “Dès que possible”. Cela peut sembler la réponse la plus honnête, la plus simple à comprendre de tous et la plus facile à gérer ; mais en fait il s’agit souvent d’un pis-aller qui démontre que le projet n’est pas réellement pris en main.

Quand on demande un développement ASAP (as soon as possible), on abdique sur tous les facteurs qui définissent un projet :

  • La définition exacte du projet n’a pas été faite correctement. On sait bien qu’on n’a pas pris le temps de réfléchir à tous les cas limites, à penser à toutes les situations. On sait − mais on ne le dit pas ouvertement − que les développeurs devront affronter tous ces culs-de-sac fonctionnels au fur et à mesure qu’ils se casseront les dents dessus, ce qui empêche d’apporter une quelconque valeur aux estimations qu’ils peuvent faire de leurs développements.
  • À partir du moment où la seule contrainte exprimée est celle du temps passé sur le projet, on accepte implicitement que des raccourcis soient fait pour atteindre l’objectif au plus vite. Un aspect en pâtira forcément, qu’il s’agisse de la qualité générale de la réalisation, de la maintenabilité du code, des tests, du débuggage, …
  • À l’inverse, l’absence de deadline réaliste autorise les développeurs à se lancer dans des développements inutiles (je ne parle même pas de ceux qui se tournent les pouces). On arrive ainsi à des situations où on découvre au bout de 2 semaines que le développement “ASAP” aurait pu durer 4 jours si on avait pris le temps de dimensionner et budgéter le projet correctement ; mais si on en fait la remarque au(x) développeur(s), on obtient une réponse du genre «Ah, moi j’estime que tout ce que j’ai fait était nécessaire pour que le projet fonctionne correctement. Il fallait me prévenir si c’était plus urgent que ça !».

Continuer la lecture de « Les premiers enseignements de Rework »

La R&D : pour ne pas confondre développement et veille techno

Il y a quelques temps, je vous ai parlé de la veille technologique. Je vous ai expliqué en quoi c’est un élément important de nos vies professionnelles.

Je voudrais cette fois-ci vous mettre en garde contre une dérive finalement assez commune chez les jeunes développeurs, qui est d’utiliser les projets professionnels comme un terrain de jeu pour réaliser leurs expérimentations. Ensuite nous réfléchirons aux moyens de canaliser la fougue qui conduit à ces dérapages.

Les expérimentations au boulot

Il y a quelques années, alors que j’étais chef de projet, un de mes développeurs – un prestataire externe, en fait – avait demandé une demi-journée de congé pour assister à une conférence organisée par Google France. J’étais content de voir qu’il prenait à coeur sa veille technologique.
À son retour, je lui ai évidemment demandé de me faire une présentation rapide de ce qu’il avait vu. Il s’agissait des premières versions des toolkits de Google, et ça avait l’air vraiment intéressant.

Nous étions alors en train de démarrer un nouveau projet, et ce développeur était en charge de certaines spécifications techniques. Quand j’ai vu dans ses specs qu’il envisageait d’utiliser les technologies Google qu’il venait d’entrapercevoir, j’ai eu une petite discussion avec lui.

Le message tient en 2 points :

  • Bien qu’absolument nécessaire, la veille technologie est une démarche personnelle. C’est à chacun de se trouver ses propres petits projets qui lui permettront de tester de nouvelles technos ou de nouveaux outils.
  • Un projet mené au sein de l’entreprise répond à des contraintes contractuelles et financières. Vouloir y glisser des technologies qui ne sont encore qu’à l’état de bêta, ou qu’on ne maîtrise absolument pas, est une erreur assez grave.

Canaliser et organiser

Il n’empêche qu’il n’est pas logique d’inciter à la veille tout en la réprimant dans le cadre de l’entreprise. L’entreprise a certains devoirs de formation vis-à-vis de ses employés, il faut s’en occuper de manière raisonnée et planifiée.

Continuer la lecture de « La R&D : pour ne pas confondre développement et veille techno »

La refactorisation

La refactorisation est un exercice qui devrait être maîtrisé par tous les développeurs, encadré par tous les chefs de projets et encouragé par tous les directeurs techniques.

Le refactoring, qu’est-ce que c’est ?

Derrière cet affreux anglicisme se cache le fait de réécrire du code qui a déjà été développé. Le but n’est donc pas d’ajouter de nouvelles fonctionnalités, mais plutôt d’assurer un suivi de l’existant, de faire un ménage qui en facilitera la maintenance.

Nous nous sommes tous retrouvés un jour ou l’autre devant des bouts de code sans queue ni tête, manifestement écrits à la va-vite, ne respectant aucune norme, avec une documentation périmée, sans commentaire, ou truffés de code mort. À chaque fois, nous sommes horrifiés. Dans le meilleur des cas, on se souvient des raisons historiques qui ont conduit à cela (« Ah oui, ça date du projet X, qu’on avait dû faire à toute vitesse il y a 2 ans ») ; dans le pire des cas, on va retrouver le responsable de cette horreur pour lui passer un savon.

Mais la bonne attitude, c’est d’organiser l’amélioration de ce code. Il faut garder en tête qu’on ne travaille pas continuellement sur les mêmes fichiers. Ce qu’on est en train de développer un jour sera utilisé pendant des mois voire des années sans qu’on revienne dessus. Mais au fil du temps, le code ancien devient « friable » : chaque correction de bug devient plus délicate et sujette aux bugs de régression ; chaque ajout de fonctionnalité prend de plus en plus de temps et devient plus difficile.

Je vais faire un parallèle avec la construction immobilière. Quand on construit une maison, on commence par faire les fondations, puis on monte les murs extérieurs, puis le toit et enfin les cloisons intérieures. Quand on développe un logiciel, c’est un peu la même chose ; chaque développement, chaque ajout de fonctionnalité, s’appuie sur des objets ou des librairies qui doivent rester fiables dans le temps. Il faut donc pouvoir revenir à tout moment sur n’importe quel bout de code, accéder à sa documentation, lui ajouter de nouvelles capacités, voire résoudre des bugs qui ne s’étaient encore jamais déclarés.
Parce que le jour où vous faites tomber des cloisons, vous ne devez pas devoir refaire les murs extérieurs ; et si vous ajoutez une étage à votre maison, vous devez pouvoir faire confiance à la chape de béton de vos fondations.

Comment s’y prendre

On peut découper un refactoring en 4 étapes précises. Les trois premières sont importantes et nécessaires, alors que la dernière est à mettre en oeuvre si le besoin s’en fait sentir uniquement.

Continuer la lecture de « La refactorisation »

Scrum : introduction

Scrum est une méthode de gestion de projet très intéressante. Pour mon premier article à son propos, je vais vous la présenter rapidement, et vous parler de l’un de ses concepts-clés : les sprints.

Scrum est une méthode agile qui ne se focalise pas spécialement sur les techniques de développement, mais plutôt sur l’organisation de projet et la gestion d’équipe. C’est une méthode moderne qui a fait ses preuves dans de nombreuses circonstances.

Présentation des rôles

L’image suivante présente d’une manière assez synthétique les différents rôles qui interviennent dans une équipe Scrum :

Scrum

(image © Avangel, Wikipedia)

  • Le directeur de produit : (aussi appelé Product Owner) Je préfère utiliser le terme de chef de projet fonctionnel. Son rôle est de présenter à l’équipe les fonctionnalités qu’elle devra développer, et de transmettre l’ordre de priorités. Il opère un suivi régulier avec l’équipe de développement, et remonte régulièrement les informations d’avancement au client.
  • Le Scrum Master : C’est un personnage très spécial qui prend en charge tous les aspects non techniques pour « protéger » l’équipe, particulièrement pendant les périodes de sprint (voir plus bas). Toutes les requêtes doivent passer par lui, pour s’assurer du respect de la méthode. C’est un rôle qu’on pourrait approcher de celui que je tiens – en tant que directeur technique – vis-à-vis de mes développeurs (hormis que je gère en plus des aspects techniques comme la validation des spécifications techniques).
  • L’équipe de développement : La théorie voudrait que l’équipe soit auto-gérée, et que ses membres prennent eux-mêmes leurs décisions de manière collégiale. D’expérience, j’ai rarement vu une équipe fonctionner correctement quand on la laisse faire ce qu’elle veut. Pour que ça fonctionne, il faut avoir des développeurs très compétents, avec de l’expérience, et surtout qui apprécie les contacts humains. Et malheureusement, toutes les équipes ont leurs stagiaires, leurs pas-très-bons-techniquement ou leurs autistes…

Les sprints

Au coeur de Scrum, il y a la notion de sprint. Le principe est de définir un lot de fonctionnalités à développer, puis de partir dans une phase de développement de durée « raisonnable » (2 à 4 semaines). Évidemment, l’ensemble des fonctionnalités doit avoir été prévu pour pouvoir être développé dans ce laps de temps.

L’important dans cet exercice, c’est de bien comprendre – et surtout faire comprendre aux autres acteurs – qu’une fois qu’on a défini la liste des fonctionnalités et qu’on a écrit les spécifications fonctionnelles, on entre dans une phase de quelques semaines pendant laquelle il est absolument interdit de changer les objectifs de développement. Cela a pour effet de pousser les clients à bien spécifier leurs besoins, car une fois que le sprint est lancé, il n’est pas possible d’ajouter de nouvelles fonctionnalités ni de changer l’ordre de priorité.

Continuer la lecture de « Scrum : introduction »