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

AmauryOrganisation d'équipeLaissez un commentaire sur 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.

La refactorisation

AmauryOrganisation d'équipe4 commentaires sur 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.

FineFS, système de fichiers redondé

AmauryQuestions techniques9 commentaires sur FineFS, système de fichiers redondé

J’ai lancé depuis quelques temps un projet dans mon entreprise, que nous venons de publier sous licence libre. Il s’agit d’un système de fichiers répliqué du nom de FineFS.

Je vais en parler ici parce qu’il s’agit d’un projet intéressant d’un point de vue technique, sur lequel les esprits imaginatifs peuvent venir s’éclater avec nous. Mais aussi parce qu’à travers ce projet, je veux vous présenter l’univers des systèmes répartis/distribués/redondés et des bases de données à très haute disponibilité – que tout directeur technique doit connaître un minimum.

Présentation du projet

Le but de ce projet est de faciliter la création de cluster-disque. Lorsque vous avez plusieurs serveurs qui doivent accéder aux mêmes fichiers, il est toujours délicat de mettre en place une architecture satisfaisante sans dépenser des sommes folles. Et pourtant, la moindre infrastructure Web présente plusieurs serveurs frontaux, qui doivent délivrer des contenus (images, vidéos, musiques) communs. Sans compter que ces différents serveurs doivent aussi pouvoir enregistrer de nouveaux fichiers, qui doivent être accessibles à toutes les autres machines.

Il existe plusieurs moyens de mettre des fichiers à dispositions de plusieurs serveurs :

  • Installer un NAS, c’est-à-dire un serveur de fichiers. Mais si ce serveur tombe en panne, plus aucun fichier n’est accessible.
  • Installer un SAN, qui prend souvent la forme d’une baie de stockage redondée. Mais les prix de ce genre d’installation grimpent très vite.
  • Utiliser un service externe, comme Amazon S3, qui prend en charge les aspects complexes de la gestion des fichiers. C’est souvent une solution satisfaisante pour du Web, mais qui peut induire des latences dans les accès aux fichiers, et des coûts inutiles.
  • Mettre en place un système de fichiers réparti, redondé et/ou distribué.

C’est dans cette dernière catégorie que se place FineFS. Il existe déjà des solutions qui s’emploient à résoudre ce besoin, qu’on peut répartir en 5 groupes :

Créer une micro-startup

AmauryCréation d'entreprise11 commentaires sur Créer une micro-startup

Je réfléchissais depuis longtemps à un concept que j’avais du mal à formaliser dans ma tête. C’était un ensemble d’idées très vagues, mais tout s’est cristallisé en deux temps. Tout d’abord en lisant le livre Getting Real écrit par 37Signals, puis en tombant sur un billet intitulé The Future of Startups sur le blog de Jason Calanis.

Le concept en question est finalement assez simple : L’heure est venue pour les micro-startups

Reprenons depuis le début. Si vous avez lu la présentation du blog, vous savez que j’ai écrit – il y a plus de 2 ans – sur mon blog personnel un article intitulé Créer une startup rapidement. J’ai donnais un certain nombre d’informations et de conseil pour démarrer une activité sur Internet. Et je me suis servi moi-même de ces informations quand j’ai créé ma propre startup, à peine quelques mois plus tard.

Le message global était qu’il est désormais très facile, d’un point de vue technique, de démarrer une activité. Tous les outils nécessaires sont disponibles à très faible coût. Le « ticket d’entrée » pour créer une entreprise est désormais très accessible.

L’évolution des mentalités

Il y a quelques années, une partie non négligeable de la valeur d’une start-up pouvait résider dans ses serveurs, leur utilisation, les logiciels et techniques spécifiques développés en interne par l’entreprise. Et une part importante des coûts correspondait à l’embauche du personnel, à la location de locaux professionnels, à l’achat de matériel informatique spécialisé.
La moindre création d’activité devait commencer par une longue période de recherche et développement, qui pouvait mettre en péril la santé financière de l’entreprise, avant même qu’elle ait démarré la moindre activité !

De nos jours, les choses sont bien plus simples et moins coûteuses.

  • La majeure partie des aspects techniques sont suffisamment balisés pour qu’il n’y ait pas à se poser trop de questions à leur sujet – à moins de développer une solution particulièrement innovante, évidemment.
  • Des solutions techniques évolutives existent, qui s’adaptent aux besoins et permettent ainsi d’ajuster son budget.
  • Les logiciels libres couvrent de très nombreux domaines. Il est facile de trouver les logiciels qui couvrent nos besoins. Même en les modifiant pour les adapter, cela restera toujours moins cher que de les développer de A à Z, et bien souvent que d’acheter une solution propriétaire.
  • Les solutions de travail collaboratif à distance ont atteint un degré de maturité qui permet à plusieurs personnes de travailler ensemble sans être présentent physiquement au même endroit. Ajouter à cela que maintenant tout le monde a pris l’habitude d’utiliser les réseaux sociaux, et il devient possible de créer une entreprise sans bureau.
  • Même si les sociétés de services existent depuis plusieurs décennies, il n’a jamais été aussi facile de trouver des développeurs indépendants motivés et bon marché, pour aider à créer des logiciels rapidement opérationnels.

Le triangle Qualité, Coût, Délai

AmauryOrganisation d'équipe14 commentaires sur Le triangle Qualité, Coût, Délai

Quand on doit choisir la manière d’aborder un projet, il existe 3 notions fondamentales qu’il faut connaître et évaluer : la qualité, le coût et le délai.

Triangle Qualité, Coût, Délai

Comprendre le triangle

  • Qualité : Il s’agit du soin qui est apporté à la réalisation fonctionnelle et technique du projet. Un projet de médiocre qualité remplira les besoins immédiats du client, en s’autorisant un certain nombre de raccourcis. Un projet de bonne qualité aura été spécifié pour couvrir certains besoins futurs identifiables, et offrira une ergonomie adaptée, des performances homogènes, une évolutivité étudiée, une documentation complète.
  • Coût : Un client est prêt à dépenser une certaine somme pour un projet donné. La valeur du projet peut éventuellement s’adapter à un certain nombre de critères, mais il y a forcément un seuil au-delà duquel il est impossible de le rentabiliser. La notion de coût englobe aussi bien les frais d’étude (en fonction du temps passé aux spécifications fonctionnelles et techniques) et de réalisation (suivant le nombre de développeurs nécessaires, le matériel mis à leur disposition, la présence d’une équipe de test et de validation, …), que les frais d’exploitation (matériel nécessaire pour faire tourner le projet en production, salaire de l’opérateur de maintenance, …).
  • Délai : Savoir combien de temps doit durer la réalisation d’un projet n’est pas aisé, même si cela fait partie du travail d’un ingénieur. Certains projets ne sont pas urgents, ni même importants, mais ils comportent forcément une deadline à partir de laquelle ils deviennent caducs.

La veille : préparer votre futur

AmauryVotre carrière3 commentaires sur La veille : préparer votre futur

Je discutais récemment avec un développeur que je viens d’embaucher, et je lui expliquais entre autres pourquoi il est important de maintenir une veille active. La conversation avait commencé quand je lui ai donné plusieurs magazines à lire (en l’occurrence des Linux Format et PHP Architect), pour l’aider à se plonger dans la « culture informatique » dans laquelle il allait travailler. Cela l’a laissé un peu perplexe au début, mais il a fini par reconnaître mes arguments.

Par le terme de « veille », on pense habituellement à la veille technologique ; c’est le fait de se tenir au courant des nouveautés concernant une technique ou un champ de technologies. La plupart des informaticiens sont férus d’informatique (oui, ça paraît évident), et se tiennent au courant des dernières informations. Dans certains cas, ce sera les news concernant le monde du logiciel libre, ou celles de tout ce qui gravite autour d’un langage de programmation ou d’une plate-forme particulière ; éventuellement, on trouvera des gens qui suivent avec précision les évolutions des processeurs ou les sorties des jeux vidéos. Bref, on voit de tout.

Mais une des choses qui font la différence entre un ingénieur qui fera évoluer sa carrière, et un autre qui stagnera au même niveau, c’est entre autres l’implication personnelle qu’il met dans son travail. Ce qui veut dire aussi qu’il faut prendre du temps pour mettre à jour nos connaissances et élargir nos compétences sans arrêt.

Le mauvais exemple

Je connais des développeurs qui considèrent qu’ils possèdent le savoir nécessaire et suffisant pour faire leur travail. Leur instruction et leur expérience leur permettent de résoudre la plupart des tâches habituelles, et quand ils sont face à un problème, ils cherchent un peu sur Internet et ça suffit bien souvent.

Expression visuelle

AmauryOrganisation personnelle6 commentaires sur Expression visuelle

Je suis régulièrement sidéré en voyant le nombre de personnes qui sont incapables d’expliquer simplement les idées qu’ils ont dans la tête. C’est vrai de manière générale, mais c’est encore pire quand ça concerne le domaine technique.

Dans le même domaine, je parlais dans un précédent billet de l’Elevator Pitch, la notion qui pousse à synthétiser n’importe quelle idée de manière à pouvoir en expliquer les grandes lignes en moins d’une minute.

Je comprends tout à fait que certaines personnes ne possèdent pas les talents d’orateur qui leur permettraient de faire passer leurs idées de manière fluide. Mais il existe un moyen tout simple pour y arriver : un papier et un crayon.
Quand un concept est difficile à expliquer, quand un cheminement intellectuel est complexe à suivre, quand le nombre d’interactions dépasse la mémoire immédiate, il faut avoir le réflexe de faire un dessin. Un schéma rend tout de suite les choses plus claires, plus évidentes.

Et pourtant, j’enrage de voir tous ces informaticiens qui sont incapables de représenter une architecture logicielle, simplement en dessinant des boîtes et des flèches. Je ne comprends pas ces administrateurs systèmes qui ne peuvent pas faire, à main levée, un schéma du réseau qu’ils administrent quotidiennement. Je fuis les entrepreneurs qui ne peuvent pas me faire comprendre l’originalité de leur idée en seulement 3 minutes et quelques croquis.

Pourquoi un dessin ?

Faire un dessin présente plusieurs avantages.

  1. La concision. On s’endort devant une présentation pendant laquelle l’orateur fait des phrases à rallonge. Un bon schéma est rapide à comprendre et facile à interpréter.
  2. L’universalité. D’une entreprise à l’autre, d’une technologie à l’autre, des vocabulaires spécifiques se créent naturellement. Il est facile de l’oublier et d’utiliser des mots incompréhensibles pour ceux qui nous écoutent. Un dessin incite à prendre de la distance vis-à-vis des termes métier, et force à employer des concepts plus généraux. Idéalement, un bon schéma pourrait se passer de texte ; quand la barrière de la langue elle-même est dépassée, l’accès à l’information est évident.
  3. La progressivité. Un schéma n’est pas une œuvre figée dans le temps. Quand on dessine sous les yeux de quelqu’un, on aide cette personne à découvrir des concepts, et à les associer ensemble de manière logique. On lui raconte une histoire, on lui fait suivre le chemin que l’on souhaite, et qui conduit à la compréhension globale du concept exposé.

Les outils nécessaires.

Physiquement, un schéma se fait avec n’importe quoi. Au dos d’une carte de visite, en utilisant le stylo de la serveuse du restaurant. Sur du papier de brouillon, avec la plume hors de prix de votre interlocuteur. Avec un feutre effaçable, sur le miroir d’un ascenseur. Dans une présentation « PowerPoint »… Un schéma très simple peut même être fait du bout du doigt, dans les airs.

Préparer votre évaluation annuelle

AmauryVotre carrièreLaissez un commentaire sur Préparer votre évaluation annuelle

La plupart des entreprises effectuent des entretiens annuels ou bi-annuels de leurs collaborateurs. Il sont habituellement réalisés par les managers, parfois avec l’assistance du DRH.

À quoi servent ces entretiens ?

Tout le monde attend ces entretiens avec impatience, mais souvent pour de mauvaises raisons. Un grand nombre de salariés n’y voient que le moment où va leur être annoncée leur augmentation de salaire. C’est évidemment un élément important de ces discussions, mais il ne faut pas que cela devienne une obsession qui occulte les autres aspects.

Les entretiens annuels sont un moment privilégié, pendant lequel on peut prendre un peu de recul par rapport à l’année (ou le semestre) écoulée. Le but est de récapituler les points forts et les points faibles, de revenir sur notre évolution au fil du temps ; comment on a réussi à s’améliorer, à progresser dans l’exécution de nos tâches.

Préparer l’entretien

Quelques jours avant l’entretien, prenez le temps de vous poser ces quelques questions :

  • Où en étais-je il y a un an, il y a 6 mois ? Mes supérieurs étaient-ils satisfait de mon travail ? Pourquoi ?
  • Quelle était l’évolution qu’on attendait de mois durant cette période ? Est-ce que mes objectifs étaient clairement définis ?
  • Quelles sont mes forces et mes faiblesses aujourd’hui ? En quoi sont-elles différentes d’auparavant ?
  • En toute honnêteté, quels sont mes coups d’éclats et mes ratages complets ?
  • Globalement, en suis-je là où je voudrais être ? Ai-je développé les connaissances et les capacités que je voudrais avoir ?

Quand vous avez répondu à ces questions, demandez-vous où vous voulez aller :

  • Suis-je satisfait de l’environnement technique dans lequel j’évolue, des projets sur lesquels je travaille ?
  • Dans quelle direction ma carrière doit-elle évoluer ? Qu’est-ce que je veux faire dans 6 mois, dans 1 an, dans 2 ans ?
  • De quelle aide ai-je besoin pour progresser ?

Une fois que vous avez fait le tour de ces questions (et seulement à ce moment-là), vous pouvez vous poser d’autres questions :

Travailler en période de rush

AmauryOrganisation d'équipe10 commentaires sur Travailler en période de rush

Depuis deux semaines, mon entreprise est en train de traverser une période de rush. Nous finalisons un gros projet, qui doit être déployé en production très bientôt. Cela s’est ressenti sur le nombre de posts sur ce blog, qui a drastiquement diminué.

Voilà le topo : Nous sommes en train de conclure le travail de ces 2 derniers mois, et qui va relancer le travail de ces 2 prochains mois. Comme pour tout projet d’importance, il y a un peu de retard, mais surtout un risque de retard. Il a donc fallu mettre les bouchées doubles pour s’assurer que le projet sorte dans les temps.

Mais comment faire pour que toute une équipe réussisse ce qui ressemblait un peu à un tour de force ? Comment s’assurer que tout le monde réponde présent au moment où il le faut ? Comment garder intacte la motivation alors qu’on va passer une semaine longue et difficile ?

Expliquer la situation

Tout le monde a connu des périodes de rush. Ce n’est pas agréable pour personne de faire des horaires 08h30-20h30 pendant plusieurs jours d’affilée, mais parfois il faut le faire.

Le pire des scénarii possibles, c’est lorsque les patrons mettent de plus en plus de pression au fil du temps ; ils s’énervent parce qu’ils voient le retard s’accumuler. Résultat, tout le monde commence à bosser un peu plus, par peur des éclats de nerf du boss plutôt que par envie de voir le projet aboutir.

Nous avons choisi l’optique inverse. En début de semaine, nous avons réuni l’équipe.

  1. Nous avons expliqué les raisons pour lesquelles il était important – pour l’entreprise mais aussi pour les employés – que le projet sorte dans les temps. Un projet stratégique est souvent susceptible de générer un chiffre d’affaires vital au développement de l’entreprise. La croissance de l’entreprise est synonyme de vitalité pour les emplois, de perspectives d’évolution pour les employés.
  2. Nous avons rappelé qu’après 2 mois durant lesquels tout le monde s’est investi dans le projet, nous étions maintenant dans la dernière ligne droite. Ce n’est pas le moment de ralentir ; il faut au contraire accélérer le rythme, concrétiser ce travail intensif en réussissant à le mettre en production.
  3. Nous avons présenté l’horizon des prochains mois, et comment le projet actuel conditionne directement les futures tâches de chacun. Si le projet se conclut de manière satisfaisante, ce sera un tremplin formidable qui donnera le tempo à la suite ; si par contre les choses tournent mal, tout le monde en souffrira.
  4. Nous avons demandé à tous les intervenants de jouer le jeu, de se « sortir les doigts du cul », de faire tout ce qu’ils peuvent pour faire en sorte que le projet sorte dans les temps et avec la qualité qu’on en attend. La durée de l’effort (une grosse semaine) est assez courte pour qu’on puisse y arriver.

Et vous savez quoi ? Tout le monde a répondu présent.