L’honnêteté paye toujours

L’honnêteté est généralement considérée comme une qualité humaine. Mais bizarrement, ce n’est pas une vertue très courante dans le monde professionnel.

Pourtant, c’est une approche qu’il faut chercher à avoir, car elle facilite grandement le travail, aussi bien quand on parle du boulot d’un développeur que de l’image d’une entreprise.

Au niveau individuel

Quand on commence à travailler, quelle que soit la branche, on a tendance à prendre assez mal les critiques. C’est le syndrôme du « petit enfant pris en faute » ; on s’en veut énormément, on a l’impression d’être en dessous de tout, et parfois on devient rouge pivoine. Avec le temps, on apprend à prendre sur soi, à faire la part des choses ; on arrive à comprendre les remontrances et à les intégrer pour progresser professionnellement, sans pour autant que cela devienne un traumatisme.
Mais cela peut avoir aussi un effet pervers. Quand on est un débutant, on remet peu en cause les remarques qui nous sont faites. Plus on progresse, plus on se sent à l’aise, et plus notre expérience professionnelle nous fournis des « armes » qui nous permettent d’embobiner nos interlocuteurs.

Combien de fois ai-je vu des gens expérimentés qui, lorsqu’ils se prenaient une remarques parce qu’ils avaient mal fait leur boulot, tournaient autour du pot pendant des heures, à expliquer pourquoi les choses s’étaient mal passées, que ce n’était pas de leur faute, qu’ils attendaient quelque chose d’un collègue, que c’était forcément un concours de circonstances, qu’il fallait incriminer les tâches solaires et les phases de la lune !
À chaque fois, il aurait été plus simple, plus rapide et plus professionnel, de répondre simplement « Ah oui, c’est ma faute. J’ai oublié tel truc ou j’ai mal fait telle chose ».

Test Driven Development

Je vous parlais récemment des tests unitaires. Je vous parlais entre autre de la difficulté d’imposer la discipline nécessaire à la réalisation de tests unitaires corrects et de leur maintien opérationnel.

Il existe une méthode de travail qui permet de forcer l’écriture des tests unitaires (tout au moins au début des développements). Il s’agit des développements guidés par les tests (ou Test Driven Development en anglais).
Cette méthode est toute simple à comprendre : Avant d’écrire un bout de code, on commence par écrire les tests qui vont vérifier la conformité du code.

Prenons l’exemple d’un code orienté objet. Imaginons que nous nous préparons à écrire une nouvelle classe.

  • On modélise l’objet, donc on connait ses méthodes publiques. On sait quelles entrées doivent produire quels résultats.
  • On écrit des tests pour vérifier les méthodes de l’objet.
  • On écrit le squelette de l’objet, avec juste les déclarations des méthodes.
  • On exécute les tests unitaires, qui tombent évidemment en échec.
  • On écrit le code de l’objet, en vérifiant que les tests passent un à un.

L’avantage avec cette manière de faire, c’est qu’au moment où le code est écrit, on est quasi-certain qu’il est conforme au comportement qu’on attend de lui. Pour peu qu’on ait pris soin de lancer régulièrement les tests unitaires au cours du développement, le code est rapide à valider.

Par contre, il va sans dire que si le TDD permet d’avoir des tests unitaires corrects pour de nouveaux développements, le problème reste entier pour l’évolution de code existant. La vigilance habituelle reste donc de mise, pour que les tests ne prennent pas la poussière. Mais il est possible de respecter cette démarche pour toutes les évolutions de code : On commence par modifier les tests unitaires existants, ou les compléter ; puis on effectue les développements qui valideront ces tests.

Mon expérience

Le TDD est ce que je qualifierais de vraie fausse bonne idée. En fait, j’ai vu plusieurs fois le même cheminement intellectuel être suivi par des équipes qui mettaient en place cette méthode :

Gestion de sources, versions de logiciels

Lorsqu’on développe un logiciel, il est absolument nécessaire d’utiliser un outil de gestion de sources. Évidemment, il serait possible de stocker ses fichiers dans un répertoire. Mais si vous voulez travailler sérieusement, vous aurez besoin de stocker les différentes versions de vos sources, pour suivre leur évolution au fil du temps ; et si vous travaillez à plusieurs sur le même projet, cela devient impossible.

Les logiciels de gestion de sources permettent à plusieurs personnes de travailler sur les mêmes fichiers, chacun dans leur coin, puis de tout rassembler pour obtenir une version continuellement à jour des sources. Ils apportent des fonctions permettant de définir des versions globales. Il existe un grand nombre de ces systèmes :

  • Les ancêtres RCS et CVS ont laissé la place à Subversion, qui offre des fonctionnalités supplémentaires bien appréciables. Ce sont des systèmes centralisés faciles à appréhender et à installer, et sont sous licence libre.
  • De nouveaux système sont apparus, basés sur un modèle décentralisé. Parmi ceux-ci, ont peut noter que les plus connus dans le monde de l’open-source sont Bazaar (sponsorisé par Canonical, à l’origine de la distribution Linux Ubuntu), Git (utilisé pour le noyau Linux) et Mercurial.
  • Du côté des logiciels propriétaires, les plus connus sont Visual SourceSafe de Microsoft et BitKeeper (qui a été utilisé pour le noyau Linux jusqu’en 2005).

Je vais vous présenter l’utilisation de ces outils, en utilisant l’exemple de Subversion (SVN en abrégé) car c’est le système de plus répandu et celui que j’utilise ; mais ces concepts sont toujours valables.

Principes généraux

Gestion basique

A la base, les sources d’un projet sont disponibles sur la branche principale (trunk). Les développeurs y récupèrent les sources (checkout) sur leur propre environnement de travail, et y ajoutent leurs versions modifiées (commit).

SVN - checkout - commit

PlanZone

Augeo est un éditeur de logiciels parisien, spécialisé depuis plus de 15 ans dans les logiciels de gestion de projets et de portefeuilles de projets. En 2008, cette entreprise a lancé PlanZone, qui est un outil de gestion de projet collaborative sur le Web. Évidemment, ce logiciel entre en concurrence avec la référence du secteur (Basecamp), mais aussi avec les autres challengers (tel que Taskii). Nous allons voir comment il se défend.

Création de projet

La découverte de PlanZone est facilitée par un assistant qui vous guide dans la création d’un premier projet. C’est le premier logiciel de ce type qui me propose de choisir parmi plusieurs modèles de projet, ce qui a une influence sur les étapes de réalisation et le type de tâches à gérer.

Bizarrement, chaque projet doit avoir une date de début et une date de fin.

Information importante : Il est possible de créer un projet en important un fichier Microsoft Project. Je n’ai pas essayé cette fonctionnalité, mais j’imagine que cela doit être pratique pour les équipes qui veulent migrer vers une solution plus agile et collaborative.

Notions et fonctionnalités

Il y a plusieurs aspects qui interviennent dans l’utilisation de PlanZone :

  • L’unité de base est le projet. Comme je le disais plus haut, un projet a un titre, une description, une date de début et une date de fin. Le terme activité est aussi utilisé comme synonyme (c’est assez déstabilisant au début).
  • Un projet peut contenir des sous-activités, qui peuvent elles-mêmes avoir des sous-activités (le tout organisé de manière hiérarchique). On se retrouve donc à gérer des « activités » au sens large, qu’on peut assimiler à des projets et des sous-projets.
  • Une activité peut contenir :
    • des sous-activités (je viens de le dire) ;
    • des ressources, c’est-à-dire des personnes qui vont pouvoir intervenir sur les tâches, avec éventuellement un décompte du temps passé ;
    • des jalons, qui comportent un titre, une description, et une date prévue d’accomplissement ;
    • des tâches, qui comportent un titre, une description, une date butoir, une priorité (basse/normale/haute), et peuvent être affectées à des utilisateurs ou des groupes d’utilisateurs ;
    • des discussions, qui affichent les messages en ordre inversement chronologique (les plus récents en premier).

Affichages des informations

Une vue synthétique présente les principaux aspects d’un projet : le pourcentage de sa réalisation et de celles de ses différents jalons, et la liste des discussions qui s’y rapportent.

La grande force de PlanZone, c’est la vue par diagramme de Gantt. C’est une fonctionnalité très rare dans les logiciels de ce type, ce qui est bien dommage.

(image © planzone.com)

Elevator Pitch

Il existe un concept très intéressant, assez connu chez les américains : le « elevator pitch ».

L’idée est simple à comprendre. Imaginons que vous ayez créé une start-up, et que vous passiez du temps à un salon pour trouver un investisseur ; bizarrement, c’est après une longue journée infructueuse que vous allez croiser un important VC, dans l’ascenseur qui vous ramène à votre chambre d’hôtel. Ou encore, vous êtes un développeur ambitieux, et vous cherchez à présenter un projet personnel au big boss de votre compagnie ; et c’est près de la machine à café que vous tombez sur lui de manière imprévue. Ou vous souhaitez conclure un gros contrat avec un client important, mais vous êtes bloqué par son directeur commercial ; là encore, ce PDG fera un jour son footing dans le même parc que vous sans que vous l’ayez prévu.

Ce genre de situations ne semblent pas si inhabituelles qu’il n’y paraît. Une quantité non négligeable de contrats se signent de cette manière.

En quoi ce concept est-il intéressant ? Eh bien parce qu’il faut être préparé à ces situations. Dans ces conditions, le but est d’éveiller l’intérêt de l’interlocuteur, de l’accrocher pour qu’il ait envie d’en savoir plus. Et cela en quelques dizaines de secondes. Cela force à aller à l’essentiel.
Être enfermé 45 secondes avec quelqu’un oblige à synthétiser ses idées, à partager une vision large des choses (celle qui est intéressante !).

Tests unitaires et intégration continue

Je vais vous parler de deux notions qui sont assez connexes, et que certaines personnes ont tendance à mélanger un peu.

Les tests unitaires

Le but des tests unitaires est d’automatiser les tests de non-régression. Quand on développe un logiciel, on peut facilement faire des modifications sans se rendre compte qu’elles introduisent des bugs dans certains cas particuliers. C’est ce qu’on appelle des bugs de régression, en ce sens qu’on introduit de nouveaux bugs à la suite d’une évolution fonctionnelle. Comme il n’est pas humainement possible de tester systématiquement tous les cas d’utilisation possible, ces bugs peuvent se retrouver déployés en production, avec tous les problèmes que cela comporte.

Une des notions importantes, quand on fait du développement, est de savoir que plus un bug est détecté tôt, plus il sera facile à corriger. Les gros soucis arrivent quand on fait du « sur-développement » par-dessus un bug de régression ; il devient très difficile de faire un retour en arrière sur le code incriminé, car cela impliquerait de supprimer des fonctionnalités. Il faut alors corriger ce nouveau code, en essayant de trouver une aiguille dans une botte de foin.

Concrètement, les tests unitaires consistent en un ensemble de scripts, qui ont chacun en charge la validation d’un morceau de code (ou d’une classe si vous faite de la programmation orientée objet). Il est assez évident de tester de la sorte les bibliothèques de fonction : les « librairies » peuvent être vues comme des boîtes noires, avec des entrées et des sorties. Il suffit d’injecter certaines données en entrée, et vérifier la conformité de ce qu’on obtient en sortie.
Pour du code applicatif, c’est un peu plus délicat, car on est parfois obligé de mettre en place un environnement de test sophistiqué (bases de données avec lots de test, génération de données aléatoires, gestion des tentatives de hack, …). Mais bien heureusement il existe de très nombreux frameworks pour vous aider à y arriver ; suivant votre plate-forme de développement, vous pouvez vous intéresser à JUnit (Java), SimpleTest (PHP), CppUnit (C++), JSUnit (Javascript), ASUnit (ActionScript), Test::Unit (Ruby), Test::Unit (Perl), unittest (Python), NUnit (.NET), …

Pas d’intégrisme technologique

J’ai rencontré trop souvent des situations où mes interlocuteurs prenaient leurs goûts personnels pour de grandes vérités technologiques. Cela m’aurait systématiquement amusé, si je n’avais pas vu trop de mauvais choix résulter de ce genre de comportement.

On a tous entendu ce genre de réflexions :

  • « PHP c’est juste bon pour faire des pages perso », venant d’un ingénieur JEE.
  • « Perl, c’est pour prototyper un logiciel avant de le coder pour de vrai », entendu chez un codeur C/Unix.
  • « DotNet, c’est une copie de Java, c’est forcément moins bien », d’un autre ingénieur JEE.
  • « MySQL ce n’est pas une base de données sérieuse », assuré par un DBA Oracle.
  • « Bah, pourquoi vous utilisez Linux ? », par un candidat à un stage habitué à Windows.
  • « Ubuntu, c’est nul, je préfère Debian », par un autre candidat.
  • « Avec la base de données et le serveur Web sur des machines différentes, on ralentit le site », par un développeur expérimenté.

On peut apporter des réponses intelligentes à toutes ces remarques :

  • Si Yahoo, Facebook et Wikipedia sont codés en PHP, c’est parce que ce sont des sites perso, hein ?
  • Pour la plupart des développements, le Perl est plus rapide à développer, avec des performances plus qu’acceptables.
  • Les développeurs qui prennent le temps de mettre le nez dans DotNet semblent dire que c’est une très bonne plate-forme.
  • Wikipedia utilise plusieurs bases MySQL, qui fonctionnent conjointement de manière très performante.
  • La vraie question est plutôt « Pourquoi utiliser Windows ? ».
  • Avec de l’Ubuntu Serveur sur les serveurs, et de l’Ubuntu Desktop sur les postes de développement, on s’assure d’avoir une plate-forme unifiée.
  • Vous imaginez que Google tourne sur une seule machine ?

Faire un choix structurant

Nous avons tous des préférences. Je me sens bien sous Linux, à coder en C et en PHP. C’est ce qui correspond à mes goûts et mes choix. Je peux l’expliquer de manière factuelle, mais il y a aussi des raisons inexplicables.

Prestation interne ou externe ?

Quand on doit choisir un outil informatique, l’une des questions que l’on doit se poser assez rapidement concerne le choix entre un outil interne à l’entreprise ou l’utilisation d’une prestation externe.

Quand je parle d’outil interne, je ne parle pas de développement réalisé en interne (même si ce cas existe bel et bien), mais des logiciels que l’on peut installer sur des machines propres à l’entreprise. Les prestations externes concernent les services qui sont disponibles à distance, souvent en SaaS (software as a service). Cela peut s’appliquer à un grand nombre de choses :

  • La gestion des emails. Votre entreprise doit-elle posséder son propre serveur SMTP, ou bien allez-vous passer par GMail/Hotmail/YahooMail ?
  • La gestion de document. Faut-il installer un serveur de fichiers interne, ou pouvez-vous vous reposer sur Google Doc/Zoho Docs ?
  • La gestion de projet. Est-il préférable d’utiliser une solution autonome, ou une plate-forme collaborative hébergée chez un prestataire ?

La prestation externe

L’utilisation d’un prestataire extérieur offre plusieurs aspects très pratiques :

  • Le service est disponible de partout (dans le cas de logiciels disponibles sur le Web). C’est très utile quand on a des collaborateurs disséminés géographiquement.
  • Le coût est limité. Les services d’email sont gratuits pour la plupart, et les offres logicielles payantes (gestion de projet, CRM, …) coûtent habituellement moins cher que la location d’un serveur.
  • La qualité du service est très bonne. Ces prestataires doivent gérer un très grand nombre d’utilisateurs, et mettent en place des architectures matérielles et logicielles prévues pour tenir la charge. Des équipes administrent ces services 24h/24, ce qui évite d’avoir à le faire soi-même.

L’installation interne

D’un autre côté, l’installation de logiciels en interne possède aussi de gros avantages :

Les erreurs à ne pas faire en entretien

Je vais réagir un peu à chaud, suite à quelques entretiens catastrophiques que j’ai fait passer dernièrement. Je vous ai déjà parlé des entretiens d’embauche, mais là je vais être très directif, presque lapidaire.

Soyez ponctuel

L’entretien d’embauche, c’est LE moment où il faut séduire le recruteur. Si vous êtes en retard le jour où vous devriez être au top, à quoi s’attendre au bout du quatrième mois de boulot sur un projet difficile ? Vous arriverez tous les jours après 11 heures du matin ?

Prenez soin de noter les coordonnées téléphoniques que vous pourrez appeler en cas de problème.

Apportez plusieurs copies de votre C.V.

Si vous arrivez les mains dans les poches, qu’est-ce que ça peut donner comme indice quant à votre envie de décrocher le poste ?

Par pitié, au moment où on vous demande « Vous avez une copie de votre C.V. ? », ne répondez surtout pas « Il est disponible sur Internet, vous pouvez l’imprimer » ! Cela revient à dire que c’est au recruteur de prendre le temps que vous n’avez pas voulu prendre vous-même.

Le plus « amusant », c’est que bien souvent le gros problème n’est pas pour le recruteur, mais pour le pauvre candidat qui se retrouve à tenter de présenter son parcours sans le support de son curriculum.

Connaissez-vous vous-même

En tant que candidat, vous devez fournir à votre interlocuteur des raisons de vouloir vous embaucher. Pour cela, vous allez lui parler de vos études et des entreprises où vous avez travaillé, mais ça ne l’intéressera pas. Ce qu’il veut, c’est que vous lui expliquiez en détail ce que vous savez faire, ce que vous avez fait, et ce que vous avez envie de faire.

Détaillez le travail que vous avez réalisé durant vos précédentes expériences professionnelles et/ou vos projets d’étude. Expliquez les problèmes que vous avez rencontrés, les solutions que vous avez appliquées, ce que vous avez appris. Dites si vous avez travaillé tout seul ou au sein d’une équipe, et alors expliquez votre rôle.

Il y a 2 situations qui sont difficilement supportables :