Deux déclarations des Droits du Développeur[1] existent dans le monde anglo-saxon à ma connaissance :

Elles diffèrent, je traduis/condense/commente :

Le droit à deux moniteurs sur son bureau

Souvent utile, parfois gadget.

Ça dépend vraiment de l’application. Qui passe son temps à écrire du code d’un côté et à vérifier l’exécution de l’autre aura plus l’utilité de deux petits moniteurs que votre serviteur suant devant Business Objects et sa ribambelle de panneaux et onglets. Je préfèrerais alors un seul très grand et très large écran, sauf dans mes périodes de rédaction de docs et support, où un A4 vertical serait optimal.

Il est clair que l’investissement de 200 € dans un écran est dérisoire par rapport au temps regagné ensuite.

(Ajout de 2010 : Et pourtant, j’ai vu des clients où même les chefs de projet informatiques en étaient resté au tube cathodique. En France à la fin de première décennie du siècle, oui.)

Le droit à une machine rapide

Tout à fait d’accord, dans les limites raisonnables évidemment. Le temps perdu à compiler, à attendre que s’ouvre une grosse application, le swap, le manque de réactivité... concourt à perdre du temps pur, à casser la concentration, et à un certain stade le gain en temps ne devient pas que quantitatif, mais aussi qualitatif.

Si je ne me plains pas de ma machine de bureau actuelle, ce serait probablement le cas avec un portable : les gros logiciels serveur comme Oracle ou Business Objects XI se lancent beaucoup plus lentement sur le disque dur escargostesque du portable courant. Et je ne parle pas de VMware.

Même si RAM et disque dur se rajoutent facilement à peu de frais, le PC de bureau n’est pas tout. Il est toujours agréable d’avoir sa base Oracle sur une vraie machine dédiée, ou de disposer d’une collection de machines virtuelles toutes prêtes rapidement accessibles sur un serveur VMware ESX bien taillé qui ne sature pas les entrées-sorties au boot d’une machine virtuelle.

D’un autre côté, n’avoir que des machines rapides pousse à la fainéantise, et masque certaines grosses lacunes en réactivité pénibles pour le client final. Dans un monde idéal, le développement aurait lieu sur une machine récente, et les tests utilisateur s’effectueraient sur une configuration relativement ancienne, limitée en processeur, mémoire, éventuellement disque.

Le choix de la souris et du clavier

100% d’accord. Je fulmine de voir que l’ergonomie de ces outils critiques est le cadet des soucis de toutes les entreprises où je suis passé. (Par contre, certains de mes clients investissent visiblement au niveau des bureaux, chaises, support pour portables plus que pour le clavier à proprement parler ; mais je ne suis qu’un simple prestataire qui hérite plus souvent qu’à son tour de la machine la moins récente, le clavier le plus crade, et d’une chaise non réglable.)

Le droit à une chaise confortable

À raison de huit heures par jour de résidence, cet endroit doit être non seulement tolérable mais aussi confortable (“Sure, you hire developers primarily for their giant brains, but don't forget your developers’ other assets.”)

Le droit à une connexion internet rapide

Vue mon utilisation massive de Google et des divers sites de docs et d’aide en ligne ou de support, un internet asthmatique provoque vite frustration, énervement, et perte de productivité.

De nos jours, le réseau fonctionne en général bien, et si Youtube n’est peut-être pas vraiment nécessaire professionnellement, je dois parfois télécharger des gigaoctets de bases de données de client, ou d’outils d’Oracle à tester. Pêchent souvent par contre les liaisons VPN vers les clients, avec un désastreux impact sur la productivité : dans le cas extrême d’une liaison inutilisable, un débogage se passe vingt fois plus lentement par téléphone, ou nécessite un déplacement parfois lointain coûteux en temps, fatigue, euros et CO₂[3].

De plus, il n’y a pas que les digital natives à tomber rapidement en état de manque du réseau et de sa mine d’informations plus ou moins utiles. Couper Internet aux informaticiens, c’est s’assurer une fuite des cerveaux.

Un coin au calme

À l'agence je vis dans un open space. Chez beaucoup de clients aussi. Les bureaux à trois ne sont pas non plus terribles pour la productivité. Il n’y a pas de formule idéale, ou plutôt une formule qui change avec la tâche : war room pour les projets tendus ou en phase de test, et bureaux isolés pour rester concentrés ou pour téléphoner, ce qui suppose que les ordinateurs soient portables.

Le droit de bien faire son travail

Voici les revendications non matérielles, les plus délicates.

Combien de fois a-t-il fallu torcher quelque chose vite fait par manque de temps ? N jours ont été vendus au client, 2N auraient été nécessaires pour tout faire calmement, donc on a tout fait en même temps, développé des morceaux sur des bases instables, testé avant la fin du développement, déployé avant la fin des tests préliminaires, et formé avant d’avoir finalisé les spécifications.

Évidemment dans ce cas les développeurs dépensent plus de temps et d’énergie à resserrer les boulons et à s’insulter mutuellement qu’ils n’en auraient pris à faire les choses proprement d’entrée. Bien sûr, la date de livraison a été fixée pour des raisons de politique interne au client, et/ou un temps fou a été paumé en administratif, et/ou tout a été décidé au dernier moment. Au final, personne n’est content du résultat et rejette la faute sur les autres.

Le droit de choisir ses outils

« On reconnaît le bon ouvrier à ses outils » dit le proverbe. Je ne me souviens pas de beaucoup de moments où j’ai pu librement choisir quelle base, quel langage, quel ETL, quel outil, quelle machine... serait utilisé. Les critères de choix portent plus souvent sur le tarif ou la compatibilité avec l’existant que sur l’aisance de développement. (Le choix de l’outil étant souvent « structurant » et engageant l’entreprise pour longtemps, je comprends parfaitement que l’opinion du développeur ne soit qu’un facteur parmi d’autres - mais rares également sont ceux qui m’ont demandé mon avis.)

Quand on parle de technique, et de choses pas trop chères (disque dur, RAM), il suffit parfois de demander pour avoir (à supposer que l’accord du chef suffise). Dès qu’il y a des coûts de licence impliqués, le programmeur de base n’a plus trop le choix. Les logiciels libres ont l’immense avantage de n’impliquer aucune bataille bureaucratique pour débloquer quelques euros de licence.

Le droit de savoir ce qu’on lui demande, avec des priorités claires

Arf arf arf.

Soyons juste, j’ai vu le pire comme le meilleur, des specs au crayon sur une feuille comme des dossiers archi-précis. Il y a forcément toujours des zones d’ombres, et le demandeur n’est pas toujours conscient lui-même de la complexité intrinsèque de son projet ou de l’incohérence parfois catastrophique de ses données source (garbage in, garbage out si logiciel != Google, et encore).

Mais les commanditaires doivent savoir répondre aux questions, corriger les incohérences remontées, connaître leur métier, savoir ce qu’ils veulent, accepter de vivre avec des contraintes techniques, et (ô qualité rare) arbitrer !

Le droit à une communication claire et directe avec le client, l’utilisateur comme le « commanditaire »

J’ai toujours haï l’effet « téléphone arabe » et les incompréhensions parfois catastrophiques nées de l’éloignement.

Autant j’abhorre passer mon temps sur la route pour aller chez des clients lointains, autant je sais que dans les situations un peu tendues ou floues la communication en face à face est dix fois plus efficace que mail et téléphone pour diverses raisons :

  • les non-dits : l’interlocuteur muet après à une question directe, ou affichant une moue, livre une information, un avertissement, montre un souci ; celui ne répond pas à un mail... peut ne pas l’avoir lu ou pas compris ;
  • la nullité de beaucoup de personnes pour s’exprimer par email, alors qu’oralement tout va bien (moi c’est l’inverse) ;
  • à l’inverse, l’incapacité de beaucoup de gens à lire un mail de plus de trois lignes (par manque de temps parfois, de cellules grises rarement, de capacité d’attention souvent) ;
  • les insinuations et autres vacheries plus ou moins gratuites que l’on n’oserait jamais par mail ;
  • la franchise entre quatre yeux, sans témoin ni trace écrite, qui permet des explications parfois très saines en cas de conflit (purement technique le conflit parfois) ;
  • la solidarité entre « gens du front » d’entités différentes mais cohabitant dans le même bureau, soudés face à leurs chefs respectifs pour le bien du projet ;
  • « radio moquette » à la machine à café : on y apprend beaucoup sur un peu tout le monde, les qualités et défauts des uns et des autres, les contraintes, les vraies raisons de ci ou ça, le vocabulaire local (capital !), la culture du client (caricature de fonction publique ? start-up hystérique ? ingénieurs pointilleux ? commerciaux-girouettes ?), l’historique (toujours chargé), les vrais arbitrages à faire, la politique interne (de quel chef se méfier ? lequel fera pression ? lequel est ennuyé par le projet ?), les hiérarchies officielles et officieuses, les personnalités (quel chef se battra pour le projet ? lequel est une carpette ?), etc. ;
  • le contact direct avec l’utilisateur : on lit très vite un brain overflow sur un visage, alors que personne ou presque n’écrira « je ne comprends pas » ;
  • le lien entre humains, tout simplement : on se décarcasse beaucoup plus pour Jacquot avec qui on a déjà sympathisé autour d’un café, une secrétaire sympa qui a dépanné l’imprimante avec le sourire, un voisin de bureau qui a conseillé sur le choix d’une voiture, un utilisateur régulier dont on comprend le martyre quotidien devant un logiciel foireux... que pour des noms abstraits sur un écran.[4]

Le pire des cas ? La spécification retransmise à un développeur lointain (indien ou français, ce n’est pas le problème) via un intermédiaire obligé ignorant du sujet[5]. À l’inverse, je me rappelle avec émotion de sessions de développement avec des utilisateurs demandeurs deux bureaux plus loin, qui savaient ce qu’ils voulaient, répondaient aux questions, et testaient. Même avec des specs-brouillon.

Notes

[1] Traduction imparfaite du Bill Of Rights qui amende la Constitution américaine, alors que la Déclaration des Droits de l’Homme constitue le préambule de toute Constitution française digne de ce nom. Différence philosophique ou simple héritage de la philogénie du droit ?

[2] On remarque les vétérans du réseau à un nom de domaine avec deux lettres seulement.

[3] Le CO₂ et la fatigue, l’employeur s’en fiche, bien sûr.

[4] Je pense que réside là une des explications des dérapages de grandes entreprises : le client contacté uniquement par web ou email devient immédiatement abstrait.

[5] L’intermédiaire c’était moi et je n’ai pas du tout aimé.