Je vous suggère de poser la question pour discussion à l'équipe. Présentez vos préoccupations à la prochaine réunion d'équipe et demandez-leur ce qu'ils en pensent.

Puisqu'elles semblent valables, j'imagine que vous obtiendrez le soutien des autres développeurs.

Assurez-vous que la discussion reste professionnelle et gardez l'esprit ouvert. Concentrez-vous sur la façon dont l'utilisation de X affecte le reste de l'équipe. De cette façon, le développeur sera moins susceptible de devenir défensif et lorsqu'il réalisera comment son utilisation de X affecte le reste de l'équipe, il lui sera très difficile de simplement ignorer leurs préoccupations.

Comment puis-je gérer le risque pour le projet présenté par X?

Pour résoudre ce problème, je vais utiliser vos propres mots:

il évolue rapidement / instable - en allant documenter un code plus ancien, il a trouvé que certaines fonctionnalités de base avaient été supprimées, ne se compileraient pas dans les versions plus récentes, il a donc fallu quelques jours pour le réimplémenter

ET

les autres développeurs sont clairement mal à l'aise avec X malgré quelques mois d'exposition. J'ai vu des problèmes de site en direct dus au déploiement de code cassé lorsqu'il était absent. Oui, une conversation est nécessaire autour des tests, mais le fait de ne pas pouvoir repérer les erreurs showstopper dans X est un drapeau rouge

Ce langage est évidemment pas très mature . Construire votre empire sur des sables mouvants n'est pas un bon plan, et je pense que vous le savez. En tant que gestionnaire, c'est à vous de gérer le risque et de définir les normes .

X est-il vraiment le problème?

Je pense que le problème est peut-être qu'il n'y a pas de normes définies dans votre groupe . Je suggérerais que vous et votre équipe conveniez des langues qui seront utilisées et que vous avanciez ensuite.

Toute nouvelle technologie doit être présentée à l'équipe avant d'être utilisée en production . Lorsqu'une nouvelle technologie est présentée, l'équipe vote alors sur la validité de la technologie. De cette façon, il n'y a pas un seul méchant si X doit être rejeté.

De plus, et c'est vraiment important pour vous: vous devez être capable de supporter le code lorsqu'un développeur quitte. Si vous autorisez des offs, cela devient plus difficile pour vous. Vous voudrez peut-être également faire des recherches sur la popularité de ces langues et leur utilisation pour vous assurer de pouvoir recruter de l'aide le moment venu.

Je serais très, très inquiet à ce sujet.

S'il est renversé par un bus demain ou décide de partir demain, alors vous avez actuellement:

• Un coût énorme, à la fois en temps et en argent, pour trouver un expert en X pour le remplacer;
• Une équipe qui ne comprend aucun des codes qu'il a écrits;
• Une équipe qui ne peut même pas déployer de manière fiable le code qu'il a écrit;
• Code qui ne fonctionnera probablement qu'avec une version spécifique et inconnue de X, et rompre avec les versions futures.

Vos supérieurs pleuvent alors sur vous comme une tonne de briques qui vous demandent pourquoi diable vous laissez cela se produire en premier lieu.

Vous dites que c'est un gars sympa - juste trop enthousiaste, alors je lui soumettrais ces problèmes, ainsi qu'à toute l'équipe en général. Demandez leur avis sur les solutions. Insistez sur le fait qu'il ne s'agit pas d'une punition ou de tout ce qu'ils ont mal fait, mais simplement d'un problème potentiel que vous devez tous résoudre. Insistez sur le fait qu'il ne s'agit pas d'un problème lié à la langue , mais plutôt à la entreprise . Assurez-vous que vous êtes ouvert aux critiques si votre compréhension de l'un des points ci-dessus est incorrecte, mais sinon, vous devez rester sur la bonne voie en vous assurant que:

• Aucun nouveau code n'est écrit X;
• De préférence, vous avez un plan à plus long terme pour migrer le code existant qu'il a écrit en X vers une autre langue.

Cela ne veut pas dire qu'il ne devrait pas être instrumentale pour choisir un autre langage plus approprié qui puisse être utilisé, et cela ne veut pas dire qu'il doit abandonner complètement X. Peut-être pourriez-vous organiser des ateliers ou des présentations où il démontre de nouveaux modèles / paradigmes en X, et comment ils peuvent s'appliquer à (langage pertinent pour le lieu de travail.) Peut-être qu'il peut rechercher un autre langage plus courant, mais qui possède davantage les propriétés de X.

Cependant, si j'étais le chef d'équipe, je ne voudrais certainement pas autoriser l'utilisation d'un tel langage dans un contexte commercial critique.

Difficile non.

Les langages familiers, ou même un nombre excessif de langues, être introduits dans un projet le rendent totalement impossible à maintenir à long terme. Lorsque le développeur partira, vous vous retrouverez avec le code dans son langage familier quel que soit l'état dans lequel il l'a laissé, et une pile de solutions de contournement dans les autres composants pour faire avancer les choses sans avoir à changer le code que personne ne comprend. Je parle d'expérience sur des projets où cela s'est produit.

Absolument pas! Des entreprises entières sont mortes parce qu'elles ont choisi la mauvaise langue dans laquelle écrire leur base de code. Si le langage meurt, devient impopulaire ou entraîne des problèmes d'évolutivité insolubles, le code meurt également. Pouvez-vous vous permettre de le réécrire?

Lorsque vous avez besoin de réécrire complètement un logiciel dans une langue différente, vous serez un canard assis, car vous ne pouvez pas sortir un nouveau produit tant que la fonction de réécriture n'est pas proche parité avec l'ancien produit. S'il est possible d'éviter une réécriture, vous devriez!.

Études de cas:

• Twitter a souffert de fréquentes baleines échouées, et finalement réécrit leur serveur Ruby on Rails.
• WordPerfect a été écrasé par Microsoft Word. Bien qu'il existe de nombreuses raisons commerciales à leur chute, une partie de leur problème était que une grande partie du code a été écrite en langage d'assemblage, ce qui rend le portage vers Windows difficile.
• John Ousterhout , qui a inventé le langage Tcl, a fondé Ajuba Solutions, une société dont les logiciels étaient principalement écrits en Tcl. Bien qu'il n'y ait pas vraiment de problème technique avec Tcl, ce n'était tout simplement pas si populaire. Son entreprise comptait quelques développeurs Tcl talentueux et dévoués, mais il était difficile de les embaucher. Finalement, la société a été acquise, la base de code a été abandonnée et la majorité des développeurs ont perdu tout intérêt à travailler après l'acquisition.

Aucun langage de programmation n'excelle dans tout, et vous voulez des développeurs pour être en mesure de choisir le bon outil pour le travail. Cela dit, il doit y avoir des contraintes lors de l'introduction de langages dans la base de code de votre entreprise. Quelques critères à prendre en compte:

• Votre équipe doit maîtriser suffisamment la langue pour qu'il puisse y avoir des révisions de code et plusieurs responsables.
• Vous devez être en mesure de embaucher des programmeurs prêts à travailler dans la langue et son écosystème. (Et vous devez être capable de tolérer les types de développeurs qui ont tendance à se tourner vers ces langages.)
• Le langage doit être suffisamment polyvalent pour rendre l'investissement rentable.
• Vous devez reconnaître et accepter les risques associés au langage (par exemple, des changements incompatibles fréquents, des vulnérabilités de sécurité fréquentes, la qualité de la bibliothèque standard, l'évolutivité , sécurité de la mémoire, lisibilité, stratégies de gestion des erreurs, comportement peu intuitif, etc.)

Parfois, il peut y avoir des facteurs atténuants au risque de choisir un langage plus obscur. Par exemple, un langage peut interagir avec d'autres langages sur une machine virtuelle Java ou le Common Language Runtime de Microsoft. Ou le langage (par exemple Swift) peut être conçu pour interagir avec un autre (Objective-C). L'interopérabilité vous donne au moins un chemin de migration qui ne vous laisse pas bloqué lors d'une réécriture.

Vous pourriez envisager d'accorder plus de flexibilité pour le code jetable ou le code prototype. Parfois, la capacité de prototyper l'emporte rapidement sur les préoccupations à long terme énumérées ci-dessus. Sachez cependant que les prototypes peuvent avoir tendance à devenir des solutions permanentes.

Dans votre cas particulier, vous avez dit que vous avez un site Web basé sur des microservices, dont certaines parties sont implémentées dans une autre langue. Même si vous ne pariez pas sur l'avenir de votre entreprise sur le langage X , mélanger inutilement les langages d'implémentation nuit à la construction d'une architecture cohérente. ( Le fait qu’un seul développeur ait la liberté totale de régner sur une partie du projet soulève un signal d'alarme concernant le manque de conception architecturale de votre entreprise. ) Le fait d'apprendre la langue n'est pas le seul obstacle; cela augmente également la complexité des outils de développement, de construction, d'analyse statique, de test et de déploiement. Ensuite, il y a aussi plus de bibliothèques que vous devrez patcher à l'avenir. Vous avez également mentionné que le langage introduit de temps à autre des changements incompatibles, ce qui indique qu'il s'agit d'un logiciel de qualité expérimentale et non de qualité de production. Si toute l'équipe supporte ces coûts simplement à cause des préférences personnelles d'un développeur, tout le monde va en vouloir à ce développeur, que ce soit secrètement ou ouvertement.

En général, le choix du langage de programmation (ou, d'ailleurs, les cadres de programmation) doit être une décision d'équipe et ne doit pas être prise par un seul loup solitaire ou un développeur de rock star. Il semble que votre équipe ne soit pas à l'aise avec le langage X , et le sentiment du groupe devrait être une bonne raison pour obliger le développeur non-conformiste à cesser de l'utiliser.

C'est l'une des rares choses où je pense qu'un manager devrait mettre le pied à terre et ne pas céder. Ce que fait le développeur nuira à l'entreprise à long terme. Et peu importe ce qu'est X - tout ce qui compte, c'est que votre entreprise n'a pas beaucoup d'expertise en X, et il sera difficile d'attirer une expertise dans X.

Votre développeur a tort que X est la bonne solution. Ce n'est pas parce que ce n'est pas le bon langage pour le projet, c'est le mauvais langage pour l'entreprise .

Dites à votre développeur que ses actions ne sont pas les actions d'un développeur senior, et même en dessous attentes pour un développeur normal. Indiquez clairement que ses actions ne seront pas bien reflétées dans sa prochaine évaluation des performances, et s'il continue de cette manière, cela affectera ses chances de promotion et de bonus.

Dites-lui que vous vous attendez à ce que les développeurs agir ce qui est le mieux pour l'entreprise et que vous travaillez sur un produit qui devrait être développé et entretenu pendant une longue période, et pas seulement par lui. Chaque développeur actuel et futur doit être capable de travailler sur le produit, sans avoir au préalable à apprendre une langue différente. Dites-lui que vous vous attendez à ce qu'un bon développeur réfléchisse à ce que sera la situation l'année prochaine, dans cinq ans et dix ans. Et que les décisions prises aujourd'hui auront une influence sur l'avenir.

En d'autres termes, dites-lui de laisser sa fierté à la porte et de devenir un joueur d'équipe.

X est-il lui-même le problème?

Non.

X n'est pas le problème ... pour chaque valeur de X

C'est un problème de gestion. En tant que nouveau manager, vous avez décroché une tâche difficile.

Comme d’autres l’ont dit, cette situation ne devrait pas continuer. Il semble en effet que la réponse fondamentale va être de la forme "Non, désolé, vous ne pouvez pas utiliser X." Et vous avez tout à fait le droit de le dire. Votre pire scénario est que ce développeur se fâche et quitte. Ce serait triste, mais c'est sa perogative et votre réponse devrait probablement toujours être "Non X".

En plus des problèmes déjà identifiés, un développeur se lance seul avec un langage familier

• rend la révision de code efficace impossible
• rend l'interopérabilité avec le travail d'autres développeurs difficile
• nécessite la duplication de code pour tous les utilitaires courants utilisés par X et non-X ( en particulier ceux qui sont sur mesure et qui ne se trouvent pas dans la bibliothèque standard X)
• Réduit la cohésion d'équipe, en particulier entre les factions X et non-X.

Peut-être une réponse plus utile que de simplement dire "Non X" d'une manière impétueuse est

• Demandez ce qui est particulièrement souhaitable à propos de X. S'ils sont authentiques, recherchez si certains de ces avantages pourraient être utilisés dans un langage plus standard. (Vous seriez surpris de voir combien de fonctionnalités à la mode parviennent à de nouvelles versions d'anciens langages comme C ++ et Java, ou au moins à obtenir le support de bibliothèques tierces)
• Invitez le développeur en question à prendre la tête ( mais pas sans supervision) pour développer les leçons utiles qui peuvent être tirées de X et les transférer aux meilleures pratiques de Y.
• Rassemblez quelques données pour défendre votre point de vue. Par exemple. il peut être utile de pouvoir dire «Nous avons déjà passé _% du temps de développement de X à gérer l’instabilité de X, contre _% à mettre à jour les modifications apportées à Y» ou «L’intégration et le débogage du code X ont réduit les performances de l'équipe dans son ensemble de _%.
• Vérifiez s'il existe des causes sous-jacentes à ce problème au-delà des préférences linguistiques. Par exemple, si cela révèle une culture d'équipe générale de développeurs isolés travaillant sur des fonctionnalités isolées, faites quelque chose à ce sujet. Il se peut, par exemple, que l'introduction de la programmation par paires puisse aider à aborder les racines plutôt que le symptôme.

En passant, il est possible que la bonne réponse soit «oui , faisons tous la transition pour utiliser X. " Ce n'est pas le cas ici, de manière très convaincante parce que X est petit, obscur, instable et mal adapté au problème. Cependant, supposons, par exemple, que vous soyez une boutique Android et que vous ayez un développeur qui se prépare à passer de Java à Kotlin, car Google a recommandé la transition de Java à Kotlin et a promis que Kotlin serait mieux pris en charge à l'avenir que Java. En fin de compte, ils ont tout à fait raison.

Plusieurs des mêmes préoccupations s'appliquent. Vous devrez vous soucier de la formation, de la compatibilité du code, de la réaction des membres de votre équipe et même du risque que l'un de vos développeurs n'aime tellement le changement qu'il décide de quitter. Pendant ce temps, bon nombre des mêmes mesures d'atténuation s'appliqueraient: autoriser les personnes investies à le diriger, collecter des données sur les raisons pour lesquelles la décision a été prise, écouter les différentes parties prenantes, etc.

Je pense que vous abordez le problème sous un mauvais angle .

Vous le présentez dans notre langage familier contre son problème de langage familier. Les langues ne sont que des outils, assez universels, leur choix est donc un problème secondaire.

Le vrai problème est que vous avez un chaos total en équipe . On dirait que tout le monde peut faire ce qu'il veut, en choisissant n'importe quel outil, même ceux qu'il ne connaît pas vraiment. C'est ce à quoi vous devez vous adresser.

Il est tout simplement insensé de n'avoir qu'une seule personne dans l'équipe capable de soutenir n'importe quelle partie pertinente du projet. Soit au moins 2 personnes en équipe doivent maîtriser X dans la mesure permettant la maintenance, soit X doit disparaître.

Le fait que votre développeur X-pet ne sache pas comment implémenter l'un des aspects cruciaux de X signifie que même lui ne le maîtrise pas de manière raisonnable. C'est le moment de se dire désolé, mais votre entreprise emploie des personnes pour faire le travail et non pour s'amuser à apprendre de nouveaux outils.

Une solution considérable pourrait être de lui permettre de développer des outils / fonctionnalités expérimentales dans un délai allant jusqu'à, disons, 20%. Interdire totalement X pourrait être contre-productif, si vous voulez garder ce type dans votre équipe (et vous le ferez probablement, car une équipe de 5 se transformant en équipe de 4 dans une application productive n'aidera sûrement pas à maintenir l'application).

Non, la langue X elle-même n'est pas vraiment le problème. Ce que vous avez décrit ici sont les symptômes d'un problème beaucoup plus profond qui affectera également tous les autres systèmes produits par votre équipe: l'équipe ne travaille pas vraiment en équipe mais plutôt en tant que groupe d'individus déconnectés.

Votre instinct selon lequel vous "voulez que [votre] équipe soit autonome et heureuse, la construise, ne la ferme pas" est correct; vous devez résoudre ce problème en entraînant l'équipe à le résoudre. Je commencerais par essayer de supprimer la propriété du code clair qui se produit lorsque le code écrit dans la langue X est "son" code. C'est le code de l'équipe, et l'équipe dans son ensemble doit être responsable de sa maintenance et de son extension.

Vous pouvez commencer par la façon dont les histoires (ou quel que soit votre équivalent) sont attribuées. Idéalement, tous les membres de l'équipe devraient travailler régulièrement sur toutes les parties du système, plutôt que sur des parties spécifiques du système "appartenant" à des développeurs particuliers. C'est bien si vous avez des développeurs qui sont experts dans une technologie ou des parties du système particulières alors que d'autres ne le sont pas, mais il ne devrait y avoir rien dans votre système où il n'y ait pas au moins deux développeurs qui estiment qu'ils connaissent assez bien cette partie pour être le responsable technique de toute histoire particulière où elle est un élément majeur.

La programmation en binôme et le simple fait de demander de l'aide sont des solutions typiques pour diffuser les connaissances. Extreme Programming gère cela en permettant à quiconque de choisir et d'être le chef de file d'une histoire, peu importe ce qu'il en sait ou peu, et repose sur le fait que les développeurs ne sont pas autorisés à dire "non" aux demandes de aider avec cette histoire, permettant à ce développeur, à mesure qu'il obtient son aide, d'apprendre tous les détails sanglants nécessaires pour terminer l'histoire. (L'affectation d'histoires dans XP est en fait une fonction de gestion de projet: le développeur qui gère une histoire pour cette itération est responsable de s'assurer que cela est fait, de trouver toutes les ressources nécessaires pour le faire. Cela permettra généralement au développeur d'avoir une compréhension de l'histoire à la fin de l'itération, qu'elle ait commencé avec ça ou non.)

Expliquez donc à votre équipe que vous êtes satisfait d'utiliser le langage X , ou quoi que ce soit d'autre, si toute l'équipe est d'accord sur le fait que c'est une bonne idée et accepte que si le développeur en question est gentil avec des extraterrestres, l'équipe continuera très bien sans lui. C'est alors à ce développeur de vendre ses idées techniques au sein de l'équipe. Précisez que même si l'équipe n'accepte pas de faire de X le langage de développement principal pour toutes les nouvelles fonctionnalités, cela ne signifie pas du tout qu'il ne peut pas être utilisé; peut-être pourrait-il être utilisé dans certains domaines plus petits afin de le tester et d'acquérir de l'expérience avec lui. Encouragez les révisions régulières à la fois de la façon dont la langue X détermine où elle est utilisée et de sous-systèmes spécifiques (qu'ils utilisent la langue X ou non) quant à leur fonctionnement, à quoi types de problèmes en découlent généralement, et comment les atténuer.

En m'appuyant sur d'autres réponses, je suis d'accord que les langues / technologies à utiliser dans le projet doivent être positivement sélectionnées par l'équipe avant d'être utilisées (sauf éventuellement un essai ou un cas de test de faisabilité, sans promesse ni chemin critique à être utilisé dans le projet lui-même).

Je crains que cela n'ait pas été fait, et essayer de mettre le sujet en discussion avec l'équipe maintenant ne ferait en sorte que personne ne veuille affronter le programmeur voyou et dire "non" (suite au fait que même le gestionnaire a peur de franchir cette étape).

Considérez ce qui suit comme moyen possible de résoudre ce problème: Organisez une réunion de «réinitialisation», au cours de laquelle l'équipe sélectionnera / approuvera conjointement les technologies à utiliser et à soutenir dans le projet. Faites comme si le projet venait de démarrer, qu'aucune langue n'avait été sélectionnée à ce jour et que vous partez d'une ardoise vierge. Maintenant, le fardeau de la preuve est d'arriver au «oui» pour la nouvelle langue (comme il se doit), au lieu du «non» (où cela semble être actuellement).

Vous devez faire comprendre aux supérieurs et à l'équipe que X dans son état actuel est un problème , car apparemment, personne ne comprend actuellement que ce soit le cas. Dites à tout le monde que l'équipe a besoin d'au moins deux experts X, au cas où l'un d'entre eux serait malade. Demandez une formation en X pour toute l'équipe. Chaque fois que le projet est interrompu en raison d'une mise à jour incompatible de X, ou d'un bogue trivial qui n'a pas été trouvé parce que les testeurs ne sont pas familiers avec X, lancez une discussion sur la façon d'éviter de tels incidents à l'avenir.

Soit la société décidera d'abandonner X, ou elle décidera d'aller all-in et de faire adopter X largement. Dans les deux cas, le problème de X étant un "langage familier" disparaîtra.

Et ne blâmez pas le développeur pour "nous amener X". Les développeurs accessibles et passionnés font de grands atouts de l'entreprise et d'excellents collègues. Ce n’est pas de leur faute si la direction a adhéré à son idée d’adopter X qu’elle jugeait géniale, sans évaluer les risques.

Je pense que vous devez avoir une discussion avec l'équipe sur cette langue. Laissez le développeur présenter le langage en premier, écoutez les avantages que le langage peut offrir ainsi que ses inconvénients. Faites part de vos inquiétudes concernant la stabilité, la compatibilité, etc. , etc.)) Encouragez les autres développeurs à donner leur avis.

Si la discussion tourne contre X et que vous ne voulez pas vraiment arrêter complètement ce développeur, sinon vous pouvez prendre la décision de garder le langage dans un projet unique et voir comment cela va se passer allez faire un deuxième tour lorsque le projet est terminé (honnêtement, c'est ce que je ferais quoi qu'il arrive (à moins que X ne soit une poubelle complète): laissez un petit projet unique se faire entièrement dans cette langue et faites un deuxième tour) .

PS: parfois des langages vraiment "étranges" et peu courants peuvent donner un énorme avantage dans certains projets: http://www.paulgraham.com/avg.html (Article a presque 20 ans, vous pouvez donc ignorer les technologies et les langages mais réfléchir davantage à un concept)

En haut des réponses

Je pense que le problème est lié à la confiance.

votre développeur est sûr d'utiliser X et craint d'en utiliser d'autres langue dans laquelle il n'est pas très doué.

probablement une formation sur les capacités de votre langue Y peut lui donner une certaine confiance dans l'utilisation de Y

Considérez la possibilité que votre développeur (celui qui aime vraiment X) soit sur le spectre autistique, ou du moins ait des traits autistiques. La concentration obsessionnelle sur une chose, en parlant tout le temps, peut indiquer que cette personne a une sorte de condition, ce qui rend difficile pour elle d'aborder la question objectivement.

La raison pour laquelle je dis cela est que, si tel est le cas, vous devrez peut-être traiter la question différemment de ce que vous auriez avec une personne neurotypique (c'est-à-dire «normale»). Cela ne veut pas dire que ledit développeur est moins adapté à ce travail.

Mon employeur me paie pour écrire des logiciels que nous vendons aux clients. Ils ne me paient pas pour faire ce que je veux. J'aime jouer aux jeux vidéo, par exemple, mais cela ne rapporte pas d'argent.

De même, un langage non établi comme X semble poser plus de problèmes qu'il n'en résout. Cela signifie que la productivité et les performances de toute votre équipe sont en danger, à cause d'un type qui veut faire les choses différemment.

Si l'utilisation de X peut avoir un effet positif net sur la productivité et les performances, garde le. Sinon, indiquez clairement à votre développeur qu'il doit séparer les loisirs (sa fascination pour X) du travail (ce qui paie son salaire).

Au travail, je vis un scénario un peu similaire. Dans mon ministère, il y a essentiellement deux principaux logiciels qui ont été écrits il y a longtemps et qui n'ont pas vraiment été mis à jour. Modèle d'objet anémique, mauvaises pratiques de codage, technologies et frameworks à l'ancienne ... La liste est longue.

Et bien que j'ai l'expérience et les connaissances pour introduire de nouveaux concepts, comme la conception axée sur le domaine, services et applications d'une seule page, je dois également considérer que les autres développeurs auront besoin de temps pour rattraper leur retard. C'est un équilibre délicat qui doit être trouvé.

Mais en fin de compte, vous devez vous concentrer sur le bien-être de toute votre équipe, pas sur ses membres individuels. Vous ne pouvez pas rendre tout le monde heureux. C'est une entreprise, pas une démocratie. Il est impératif d'écouter les gens, mais il est tout aussi impératif de prendre une décision et de s'assurer que tout le monde s'y tient. Sinon, ne soyez pas un chef d'équipe.