[traduction] 16 moyens de torturer vos développeurs

billet originel : 16 ways to torture developers par Andrew Oliver, le 4 mars 2013

Je dédicace cette traduction à Alexandre Rodière et à Eric Lemoine qui ont été inspirants dans ma carrière.Si vous reconnaissez certains points comme faisant partie de votre travail, je vous invite à calculer le score de votre entreprise🙂

By Kristaps B. from Tukums, Latvia (Summer’s boredom) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)%5D, via Wikimedia Commons

Avoir des bons développeurs signifie créer un super environnement. Dans un monde de compétition accrue, cela englobe tout de la nourriture gratuite à des jours de congé offerts. Mais tout le monde n’a pas reçu le message.

Quelques endroits pratiquent encore la torture de développeur. Cela peut prendre de nombreuses formes. Ne vous engagez pas dans une ou deux, car vous risquez de ne jamais plus revoir vos meilleurs développeurs de votre vie.

  1. L’enfer sécuritaire

    J’ai été à un endroit où le proxy McAfee interdisait les fichiers ZIP avec HelloWorld.java. Cela signifiait que tous les téléchargements d’exemples d’outils étaient interdits. Dans un autre endroit, le scan du poste McAfee scrutait chaque fichier auquel un processus accédait pour trouver du code malicieux, même si les fichiers n’avaient pas été modifiés depuis la dernière fois qu’ils avaient été inspectés, et en mode simple-thread, cela consiste à faire traiter le contenu complet de milliers de fichiers par un coeur de CPU pour chaque opération. Cela prenait 30 minutes de lancer l’IDE et encore 10 minutes de lancer un build, même si le build ne concernait que trois fichiers sources et ne tournait que quelques secondes.Developer

  2. Outils de torture

    Il y a Subversion, et il y a Git. Franchement, tous les autres gestionnaires de version sont vraiment trop lents et/ou douloureux. ClearCase est le pire de tous les outils de torture de développeur. Un…jour…le…code…sera…enfin…chargé…

  3. Equipes de maintenance

    Certaines boîtes ont encore des équipes figées, qui font tout le sale boulot. Sérieusement, personnes ne veut rester dans l’Equipe Maintenance dès qu’ils ont trouvé un meilleur job, et le Sort leur est favorable.

  4. Windows obligatoire

    Obliger vos développeurs à utiliser Windows comme environnement de développement s’ils n’écrivent pas du code .Net est vraiment sadique. Windows obligatoire signifie fournir à vos développeurs la même crasse que les utilisateurs non-tech sont obligés d’utiliser, avec les mêmes restrictions. (Je réalise que quelqu’un dans mon équipe dira qu’ils sont obligés d’utiliser Linux. C’est vraiment moche.)

  5. Verrouiller toutes les bibliothèques

    Il y a des années, quand je travaillais pour IBM, on me demandait de ne pas utiliser de bibliothèques tierce partie — opensource ou pas — à moins que cela ne m’économise deux mois de développement parce que la paire d’heure d’un avocat nécessaire à valider coûtait plus que deux mois de mon temps. J’ai augmenté mon taux horaire peu après. Bien entendu, vous avez besoin de règles fixant où et comment vous utiliserez des bibliothèques sans passer par une validation formelle, mais même en ce cas, « verrouillage optimiste » (optimistic locking) fonctionne généralement bien. Sans quoi vous êtes en train de commettre un acte de torture de développeur odieux en obligeant tout le monde à réinventer la roue carrée.

  6. WebSphere

    Ecoutez, je peux vivre avec DB2 maintenant qu’IBM a enfin ajouté READ_COMMITTED. Mais WebSphere c’est trop douloureux. Ne me faites pas démarrer WebSphere ou passer par les 50 écrans graphiques nécessaires pour déployer un fichier WAR. Sérieux, Webspehere est de la torture pure et simple pour un développeur. C’est mauvais. Cela a toujours été mauvais. Si vous ne devez jeter qu’une seule chose : désintallez Websphere. Autrement les développeurs vous haïront dans votre dos. S’ils ne le font pas, vous avez besoin de meilleurs développeurs.

  7. Marche ou crève

    Si vous forcez vos développeurs à une marche forcée constante, vous les épuiserez. En outre, ils vont avoir l’impression qu’ils ont fait tenir les choses par des trombones et du chatterton. Un sprint de maintenance n’est pas la solution parce que personne ne veut passer des semaines à nettoyer un gros merdier. A la place, donnez plutôt aux développeurs un peu moins de temps que ce qu’ils réclament. Quelque chose en plus sera du surcoût et quelque chose de moins est de la torture de développeurs.

  8. Ah, 2010 était une bonne année

    Donc vous aimez vraiment « standardiser » des vieilles choses, disons une version d’un IDE de 3 ou 4 ans d’âge tournant sur une version d’OS (sûrement Windows) pour laquelle il n’a pas été testé. Dans un marché compétitif d’OS, vous pouvez parier que quelqu’un va offrir des prestations complètes et la possibilité d’utiliser une version plus récente à vos développeurs.

  9. Désolé, on ne fait que les trucs ennuyeux

    Je comprends que vous détestez l’architecture HipsterHacker. Vous ne voulez pas d’un système développé sur la base de « oh, regarde ce nouveau truc bling-bling, laisse moi aussi le télécharger ». D’un autre côté, faire écrire à vos développeurs le même code, avec rien de nouveau sous le soleil les fait réfléchir à leur carrière. Mélangez : laissez vos développeurs toucher à des nouvelles choses et diminuez le risque par une architecture stable.

  10. La VM de l’éternel sablier

    Votre entreprise est totalement virtuelle ! Même les environnements de développement sont virtuels ! C’est extra, mec ! Sauf que vous n’avez pas investi cher dans le matériel ou vous ne l’avez pas bien configuré, donc tout est lent, c’est une horrible torture. Quelques personnes sont zen et ne sont pas gênées par un process de build de deux heures. Je ne fais pas partie de ces gens là.

  11. Le faux standup meeting Scrum

    Il y a un endroit spécial en enfer pour les pires pécheurs. C’est connu sous le nom de standup scrum meeting quotidien pour le management, où tout le monde est appelé à parler 5 ou 6 minutes, non pas pour transmettre des informations importantes, mais pour dire au management qu’ils sont occupés à faire quelque chose et devraient rester en poste. Le standup a forcément 12 personnes minimum, dont la vaste majorité ne devrait pas être là. Cela dure 30 à 45 minutes, voire plus (un vrai standup quotidien Scrum devrait prendre 5 à 6 minutes), et tout ceux qui ne parlent pas s’écartent un peu. Pire, personne ne travaille durant ces réunions parce qu’ils ne connaissent pas le contexte qui va arriver. Après la réunion, hé bien, la pause repas n’est qu’à une heure, alors pourquoi commencer quelque chose de difficile maintenant ?
    En gros, ces réunions coûtent à votre équipe la matinée entière, sont un poison moral et n’avancent à rien. Apprenez à faire correctement de l’agile ou arrêtez cette réunion.

  12. Formalisme

    Le formalisme c’est plus que porter une cravate, et cela peut survenir de façon inattendue. Ironiquement, les environnements détendus (sans cravate) sont plus difficiles parce qu’établir la frontière est dur, mais les développeurs ont depuis longtemps combattu les environnements formels. Quand je travaillais pour JBoss, trois directeurs du développement à la suite m’ont dit que je ne devrais pas porter chemise et pantalon de costume ensemble, et qu’ils me payeraient des habits décent à Target. Ils étaient sérieux. Le problème était que si JBoss (perçu comme une équipe en sandales) se montrait en costume, le management pourrait forcer les développeurs à porter à nouveau le costume pingouin. L’environnement détendu était, en fait, une construction artificielle. J’ai récemment essayé de mettre la barre plus haut quand j’ai engagé un RH qui m’a immédiatement demandé « Est-ce que cela signifie que nous ne pouvons plus utiliser le mot f*** ? », j’ai répondu, « Non, le mot f*** est un mot sacré, et nous le prononcerons à tout moment, en tout lieu, et pour n’importe quelle raison…à moins que des clients ne soient dans les parages. »
    Il y a une guéguerre entre les environnements boutonnés et déboutonnés qui se croisent en comment les gens parlent (comme les blagues graveleuses) et comment les gens pensent (« cela fait sens techniquement » versus « ce n’est pas mon terrain »). La plupart de tout cela est dû au fait que les grandes entreprises requièrent plus de règles, d’un autre côté, les gens aiment les rituels et le formalisme excessif dans les procédure, le langage, l’habillement et plus. Forcer les développeur à faire tout comme il faut au nom du formalisme est un abus pour l’âme et la conscience.

  13. Management par prise d’otage

    Parfois un test de charge échouera, et le management veut en connaître la cause et la solution. lls peuvent même menacer de revenir à la version précédente, même si cela casse l’implémentation. C’est un moyen parfait pour casser le process de développement. Micromanagement et affirmation d’autorité depuis tout en haut interrompt non seulement le processus itératif d’implémentation et de testing, mais cela rend les développeurs frileux de faire quoi que ce soit et d’attirer l’attention. Menacer d’actions drastiques et immédiates pour résoudre les problèmes sans comprendre les fonctionnalités conduit à un produit bâclé dans le meilleur des cas.
    Mettre le projet à la merci de clients paniquées ou de managers assure aux développeurs que la situtation est hors de leur contrôle, mais ils seront blâmés pour les problème en dépit des avertissements qu’ils auront donnés. Objectifs et délais vont de pair pour finir quelque chose. Un tourbillon de reproches le détruit.

  14. C’est nous qui posons les questions

    Disons que quelqu’un trouve une machine malicieuse qui essaie de se connecter à Skype sur un port interdit. Le développeur n’est pas au courant que cela viole les règles. Mais quand il demande des informations sur d’autres règles, aucune ne lui est fournie. Bravo : vous venez juste de punir un développeur pour avoir échoué à suivre des règles vagues, non-dites et non-documentées. Ne soyez pas surpris s’ils cherchent la sortie la plus proche.

  15. Le Diable est dans les détails

    Le boss classe sur lui : « Le client a demandé une petite modification. Pouvez-vous l’ajouter à temps pour la livraison ? » Le codeur : « Non. Cela demanderait une modification majeure de l’architecture. Nous avons demandé avant de commencer, et il nous a été demandé de ne pas prendre de temps à rendre cette sorte d’ajout possible. » Bien que les exigences soient rarement gravées dans la pierre dès le départ, faire pression sur les développeurs pour prendre le plus court chemin sans penser à aucune évolution future les met dans une position difficile lorsque la demande survient plus tard.

  16. Peu importe comment ça marche, du moment que ça marche

    Certains managers demandent des solutions immédiates aux problèmes pendant qu’ils refusent d’émettre des hypothèses sur les causes et ne font pas l’effort d’enquêter correctement. Cela conduit généralement à un échange verbal du genre de : « N’êtes-vous pas un expert ? Pourquoi ne pouvez vous pas expliquer ou résoudre cela ? » Pour trouver une solution, il faut chercher la source du problème, faire des hypothèses et tester ces hypothèses. Non, nous ne pouvons pas aller directement à la conclusion, notre méthodologie de résolution de problème n’est pas un jeu de devinettes !

Ajouter mes idées

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s