Travailler plus, non, travailler mieux, oui !!!

Voila un refrain que l’on entend rarement.

Dans les métiers de l’informatique, qui sont en crise actuellement (sauf dans la petite bulle de Saskatoon, qui semble résister à tout), le refrain qui revient souvent c’est « travailler plus pour satisfaire nos clients », « soyez plus motivé, soyez plus investi ».

C’est une belle phrase mais qui sonne souvent comme un non-sens lorsqu’on la vit de l’intérieur.

Employés, employeurs, arrêtez de dire n’importe quoi.

Au premier, chers développeurs, je dirais :

« Affûtez votre outil » ou comme le disait Abraham Lincoln « If I had six hours to chop down a tree, I’d spend the first four hours sharpening the axe. » Littéralement « Si j’avais six heures pour couper un arbre, je passerais les 4 premières heures à affûter ma hache. »

Ce qui veut dire, Messieurs, Mesdames les développeurs, réfléchissez avant de faire afin d’être plus efficace. Restez au fait des technologies, prenez le temps d’étudier les outils qui peuvent vous rendre plus efficaces, expérimentez et appliquez, en un mot, Osez !!! Vous aurez besoin de moins de temps pour la même charge de travail.

Bien sûr certains vont me répondre, mais nous n’avons pas le temps de réfléchir ou d’étudier ou d’expérimenter. En clair,  « Je n’ai pas le temps d’affûter ma hache, il faut que je coupe cet arbre. » Ben voyons !

Lorsque vous créez votre environnement de travail, prenez le temps de le configurer afin d’être le plus efficace, même si cela doit vous prendre une heure, deux heures ou huit heures. Si grâce à cette configuration, vous êtes capable de gagner 10 ou 20 minutes par jour, vous verrez que l’investissement est très vite rentable.

Il en est de même pour vos développements. J’ai l’exemple d’un développeur qui s’est « amusé » à écrire son parser pour un format de fichier XML fait maison. Alors qu’il existe des outils qui vous permettent de générer le code afin de parser automatiquement votre fichier. Dans le deuxième cas, le code est optimisé, rapide à mettre en place ou à mettre à jour. Dans le premier cas, il faut le temps de l’écrire, de le tester, le remettre à jour manuellement. Mais voila, le développeur n’avait pas le temps d’étudier l’outil. Dommage.

Au second, chers employeurs, je dirais :

Arrêtez de rogner sur des coûts, qui certes font baisser vos dépenses, mais font baisser également votre production. Alors, oui, vous pouvez compenser en faisant travailler plus vos employés, mais si ceux-ci pouvaient l’être sans toujours avoir à travailler plus.

Pour cela, quelques règles simples et rapidement rentables :

  • Fournissez un second écran voire un troisième écran à vos employés : une étude de Microsoft montre que la productivité augmente de 9 à 50%. Coût de l’opération : 200€, pour un ingénieur avec un coût de 1000 euros par mois et une productivité accrue de 15%, l’investissement est rentable en seulement un mois et demi, et vous gagnez 15% de productivité sans travailler plus. Ce qui signifie sur une journée de huit heures, une bonne heure et demie de gagnée, (mon employeur actuel l’a bien compris, j’ai eu un second écran dès le premier jour et tout le monde en a un, même la secrétaire)
  • Fournissez un espace de travail suffisamment grand. Je vois des managers expliquer qu’ils ont réussi à faire rentrer un développeur dans moins d’un mètre carré et qu’ils peuvent ainsi économiser 5000 euros par an en frais de structure. Super, mais le développeur n’a pas les moyens de poser son clavier et un cahier sur son bureau. Perte de productivité, facilement 15%, si ce n’est 25%. Par rapport au coût sur la marge totale, ça fait une belle différence et pour le salarié également. Permettez au moins à vos collaborateurs de respirer et de poser plus de 2 feuilles sur leur bureau. Fournissez leur également de quoi ranger leurs affaires, un placard, des tiroirs et pas dans la pièce d’à côté, s’il vous plaît,
  • Fournissez les outils qui augmentent la productivité. Imprimante, téléphone, logiciels et matériels de qualité. Je me rappelle avoir vu une fois, une imprimante, type imprimante personnel basique pour 80 personnes, à un autre étage dans un autre local, fermé à clé. Tout de suite, vous découragez vos développeurs d’imprimer, belle économie de papier et d’encre. Mais belle perte de productivité également. J’en ai vu d’autres qui préféraient des outils Open Source gratuits plutôt que l’investissement dans un logiciel performant mais payant. J’ai un bel exemple avec MS Project. Je passais mes vendredis entiers à essayer de mettre à jour mon super logiciel gratuit afin d’avoir des dates de fin pour mon projet, alors que la même chose était possible avec MS Project en moins d’une heure. Coût du logiciel : 1000 euros, gain de productivité : +20%. Rentabilité garantie. Je suis fan de logiciels libres, mais il faut également savoir réfléchir.

Alors à toutes ces règles simples, vous me répondrez, oui, mais moi qui vends des hommes, ça me coûte. Un développeur qui travaille plus, ça ne me coûte pas plus cher, il est payé le même prix. Et en temps de crise, il le fait même sans qu’on lui demande.

Et je ne peux que répondre :

Super !!! Logique implacable.

Publicités

MS Visual Studio 2008 : Une mauvaise copie d’Eclipse

Depuis quelques jours, j’ai l’occasion d’utiliser Visual Studio 2008 à mon travail. Ceci me permet de faire quelques comparaisons avec mes outils fétiches, Eclipse et Netbeans.

Et la conclusion est désespérante pour Microsoft.

Leur produit est plus ancien mais beaucoup moins fourni, un comble.

Voici mes arguments :

  • Pas de touche magique (Le Ctrl + Shift + 1 d’Eclipse). Et oui, ces 3 touches parfaitement positinionnées qui permettent de faire pratiquement tout ce dont vous avez besoin au moment ou vous en avez besoin. Correction d’erreurs, import de classes, renommage, complétion. Avec VS 2008, rien de tout ca, vous avez la souris et son clic droit qui permettent de faire certaines choses, mais très peu en comparaison d’Eclipse.
  • Pas d’accès facile entre les classes, vous êtes obligé d utiliser le bouton droit de la souris et de faire « go to definition ». C’est lent, demande plusieurs manoeuvre et ca m’a rebuté plus d’une fois.
  • Génération de code laborieuse. Il est difficile de trouver les générateurs de code (genre get/set), et les complétions de code se génèrent souvent sans les parenthèses nécessaires aux appels de méthodes (vides) ou sans les accolades de fin des méthodes ou blocs conditionnels. Vous êtes donc toujours obligés de fermer les accolades, VS 2008 ne le fait pas pour vous.
  • Mise à jour des erreurs très tardives parfois. VS 2008 vous indique des erreurs, assez bien, même si on aurait aimé un affichage plus lisible, mais lorsque vous corrigez ces erreurs, celles-ci restent affichées jusqu’au prochain lancement du serveur. Ce n’est pas très agréable de chercher une erreur alors que vous venez de la corriger.
  • Documentation avec peu d informations. Je crois que c’est le pire. Microsoft vous fournit une grosse documentation sur MSDN, mais pour trouver un type en entrée ou en sortie d’appels de méthodes, il faut écrire la méthode dans l’éditeur pour le savoir. C’est plutôt moyen. Quand on compare avec la javadoc, on s’aperçoit vite que MS fait beaucoup moins bien dans ce domaine. J’avais trouvé une doc assez complète dans la MSDN, j’allais féliciter MS pour ces progrès et finalement il s’agissait de documentation java. Y’a pas à dire (faudra m’expliquer ce que fait la documentation java dans MSDN).
  • Utilisation brouillon des génériques. MS a fait pareil que Java en rajoutant des génériques sur ses types. Mais pourquoi faire simple quand on peut faire compliquer. Ce sont de nouveaux types, extensions des anciens mais dans d’autres packages et avec des fonctionnalités parfois différentes. Ce qui implique des imports différents, des utilisations différentes de type en fonction du contexte de programmation. Au final, on est vite perdu dans leur utilisation. Mais pourquoi n’ont-ils pas fait comme java ? Les mêmes types mais on autorise la généricité…
  • Fonctionnement de l’éditeur différent en fonction du langage. Et oui, l’éditeur ne se comporte pas de la même façon si vous développez en VB ou en C#. La complétion par exemple, avec la touche entrée, dans un cas, elle vous renvoie à la ligne, dans l’autre elle vous laisse après le bloc compléter. Ceci s’explique surement par des raisons historiques, mais c’est quand même bien dommage.
  • Pas de surbrillance des éléments. C’est une fonction bien agréable d’Eclipse. Vous placez le curseur sur une variable, une méthode, une exception et Eclipse vous montre son utilisation dans le code. C’est particulièrement pratique pour voir les références dans le code. Sous VS 2008, cette fonctionnalité n’explique tout simplement pas. Une horreur lorsqu’on a pris l’habitude de l’utiliser.
  • Presque pas de couleur. L’éditeur de MS ne fournit quasiment pas de couleur pour la syntaxe. Beaucoup de noir, un peu de bleu clair, un peu de bleu foncé et du vert pour les commentaires, c’est tout. Pas de mise en gras ou de souligné, pas d’autres couleurs. Ca rend le code peu lisible et peu engageant.
  • Une documentation en pseudo HTML avec des balises limitées. La javadoc .Net se crée avec des balises style HTML <summary> qui sont à moitié généré. A moitié car les fins de balise sont à écrire à la main. Déjà que les développeurs n’aiment pas écrire la documentation dans le code, avec VS 2008, on dirait que MS a fait exprès de les rebuter au maximum. En plus, il n’existe qu’un nombre très limité de balise et pas de author, since ou version. Comment voulez-vous faire dans ces conditions ?

Avec tous ses défauts, on se demande ce qu’on peut trouver à VS 2008. L’éditeur a 2 ans de retard sur ses concurrents directs (Eclipse et Netbeans). Il apprend et copie des autres, mais vraisemblablement pas assez vite.

Et avec tout ca, on vous raconte que l’environnement .Net vous permet d’être plus productif. Il va falloir me donner des arguments pour me le prouver !!

Heureusement j’ai lu qu’Eclipse allait permettre d’écrire du code .Net. Voila une très grosse concurrence pour VS2008. Vite c’est où qu’on récupère le plugin ?!!!

%d blogueurs aiment cette page :