Une entreprise doit-elle passer à un certain IDE un drapeau rouge?
J'ai récemment rejoint une startup en croissance rapide. Au cours des 3 derniers mois, l'équipe de développement est passée de 4 à 12. Jusqu'à présent, ils étaient très laissez-faire sur ce que les développeurs faisaient leur travail. En fait, l'une des choses que j'ai d'abord trouvées attrayantes au sujet de l'entreprise est que la plupart des programmeurs utilisaient Linux, ou quel que soit le système d'exploitation qu'ils jugeaient le mieux adapté à leurs efforts.
Désormais, il a été ordonné, sans discussion, que tout le monde passe à Eclipse. Un bon éditeur. Je préfère SublimeText2, mais c'est juste mon goût personnel.
Juste pour être clair: nous sommes une équipe JS utilisant Backbone et Eclipse n'est tout simplement pas bon pour comprendre le code Backbone. Cela signifie que les membres de l'équipe qui utilisent un/bon/IDE (PHP Storm), doivent recommencer à faire beaucoup de recherche-trouver-oh-attendre-où-étais-je genre de choses il y a trois étapes au lieu de simplement ctrl + cliquer et utiliser en arrière/en avant - diminuant probablement la productivité de 15% et le plaisir de 50% ...
Est-ce un drapeau rouge? Il semble capricieux et déraisonnablement contrôlant de dire aux développeurs (non-MS) quels IDE ou ensembles d'outils à utiliser s'ils sont déjà installés et productifs).
"Maintenant, les ordres, sans discussion, sont venus pour que tout le monde passe à Eclipse."
Je pense que ceci est le vrai drapeau rouge. Votre équipe est l'expert en développement logiciel et celle qui sera affectée par la décision, et pourtant vous n'avez pas pu dire un mot dans la discussion qui a abouti à cet ordre?
Cela ressemble à une gestion excessive par des patrons aux cheveux pointus. La personne/l'équipe décisionnelle a-t-elle des informations pertinentes pour cette décision?
Étant donné que les décideurs sont suffisamment qualifiés pour prendre une telle décision, ne pas demander l'avis de l'équipe de développement présente au moins deux lacunes:
L'équipe ne se sent pas impliquée. L'implication de l'équipe devrait être une priorité pour la direction. Je ne voudrais pas travailler en tant que développeur quelque part où mon opinion sur des questions centrales telles que IDE n'est pas suffisamment valorisée pour être même demandée. être pire, mais dans ce cas, je m'attendrais à une justification solide pour cette décision.
La direction, quelle que soit son expérience, ne travaille pas à 100% avec le développement de ce code spécifique. En supposant que les personnes qui n'ont pas du tout de perspectives intéressantes seraient naïves. Bien sûr, c'est peut-être pour que les managers aient pensé à tout ce que les développeurs proposent, mais la seule façon de savoir est de demander.
Il est raisonnable que lorsque vous travaillez ensemble sur un projet commun, que sur chaque poste de travail vous ayez tous les outils disponibles pour éditer/construire/déboguer votre logiciel, et que les outils de base pour faire environ 90% du développement soient connus de tous dans l'équipe. Cet objectif est plus difficile à atteindre si votre équipe se développe et que tout le monde utilise son jeu d'outils personnel préféré - plus il y a de personnes, plus il y a d'opinions. Et le travail administratif devient également plus facile si vous ne laissez pas le nombre d'outils augmenter plus que nécessaire.
Bien sûr, si un développeur insiste pour utiliser son éditeur préféré personnel, cela peut être correct tant qu'il peut s'assurer que la source ne ressemble pas ou ne se comporte pas différemment dans l'éditeur principal de l'équipe (dans votre cas Eclipse), donc si dev B doit éditer la source du dev A, le dev B ne doit pas être obligé d'apprendre l'éditeur personnel préféré de A pour pouvoir changer la source efficacement. Mais attention, si les deux doivent travailler ensemble de temps en temps devant le même écran (ou faire de la programmation par paire), les choses sont souvent plus faciles si l'éditeur choisi est bien connu des deux.
Pour la programmation en binôme, c'est bien si les deux parties devant l'écran ont les mêmes compétences lors de l'utilisation du clavier. Il est également agréable de savoir que si votre projet a des besoins de configuration spéciaux dans l'IDE, il est configuré de la même manière pour tout le monde. Il est plus facile de démarrer un nouveau développeur lorsque les outils sont les mêmes pour tout le monde.
Mais si vous comparez cela à essayer d'être le plus efficace possible, cela n'en vaut pas vraiment la peine
Oui, c'est un peu un drapeau rouge que la direction considère comme un meilleur juge des outils avec lesquels vous seriez plus efficace que vous.
Ce n'est pas un drapeau rouge en soi.
Parfois la direction doit prendre des décisions. Tous les problèmes qui nécessitent une normalisation sur quelque chose ont tendance à tomber dans cette catégorie. Une fois, j'ai travaillé chez un client qui avait laissé les normes dériver pendant quelques années et ils disposaient de plus de 20 outils SCM différents. Ce qui a commencé comme un choix indépendant par différentes équipes de développement s'est transformé en un cauchemar logistique qui a gravement entravé le partage des compétences et la collaboration sur le code à travers l'organisation. La construction intégrée était ..... euh ..... pas très intégrée .....
De plus, c'est pas pratique ou nécessaire de consulter tout le monde pour chaque décision. La mesure dans laquelle cela doit être fait dépend de la culture de l'organisation et de l'importance/complexité de la décision. En règle générale, vous prendriez l'une de ces options moins consultatives:
- Prenez la décision vous-même, si vous avez une connaissance suffisante du pour/du contre et que ce n'est pas une décision suffisamment importante pour nécessiter une large consultation.
- Consultez quelques personnes clés (qui seraient probablement les développeurs seniors les plus qualifiés pour prendre la décision).
- Faites part du fait que vous prenez une décision à toutes les personnes susceptibles d'être concernées (e-mail, assemblée publique, réunions d'équipe). Dites ce que vous pensez être la bonne décision, mais que vous êtes prêt à changer cela si de nouvelles preuves émergent du contraire. Invitez les gens à se manifester individuellement s'ils ont des points de vue importants
- Invitez les gens à former une sous-équipe pour examiner les options et recommander une décision. Bonne option si c'est vraiment un appel serré, vous ne connaissez pas la réponse et vous voulez que les personnes impliquées soient prises en compte dans la décision.
Pour quelque chose comme les outils de développement (qui est un problème potentiellement litigieux), j'en ferais probablement 2 suivis de 3 ou 4. C'est-à-dire qu'il y aurait certainement des personnes à qui je ne parlerais pas personnellement sur le problème, mais d'un autre côté, la plupart des personnes clés auraient une chance de contribuer à la prise de décision.
Pour moi, le vrai drapeau rouge serait là si vous sentez fortement que la mauvaise décision a été prise (mauvais == cela nuit à l'entreprise plutôt que juste votre outil préféré n'a pas été choisi). Comment la direction réagit-elle lorsque vous soulevez ce problème:
- Une bonne direction écoutera votre argument, merci sincèrement pour les commentaires et reconsidérera sa position au cas où vous auriez soulevé de nouvelles idées . Ils ne sont peut-être toujours pas d'accord avec vous et peuvent s'en tenir à leur décision, mais ils apprécieront que vous l'ayez soulevée avec eux et vous feront la courtoisie de dire pourquoi ils s'en tiennent à leur décision. Ils pourraient même changer la façon dont ils prendront de telles décisions à l'avenir, et si vous avez fait de bons arguments, ils peuvent vous inclure sur leur liste de "personnes intelligentes à poser".
- Une mauvaise gestion deviendra défensive, disons que "la décision est prise" et d'autres tactiques de ce type pour éviter de faire face au fait qu'ils peuvent avoir pris une mauvaise décision. Ils peuvent vous voir comme un "fauteur de troubles". L'entreprise souffre, tout comme votre foi dans la gestion. C'est un vrai drapeau rouge! Sortez tant que vous le pouvez!
Si vous utilisez maven ou quelque chose de similaire, peu importe quel IDE vous utilisez. Il peut y avoir des cas où l'un est lié à un IDE spécifique comme Eclipse, s'il existe des plugins sur lesquels vous comptez.
Je pense que vous devriez pouvoir choisir votre propre IDE, le IDE dans lequel vous êtes le plus productif. Cependant, comme je l'ai déjà dit, il y a des cas où il est logique d'utiliser un IDE standard.
Chaque équipe dans laquelle j'ai été présente a eu une multiplicité de IDE et éditeurs: Eclipse, Netbeans, IDEA, VIM, Emacs, Textmate, RubyMine - cela n'a jamais été un problème. Jamais.
Pour moi, cela dénote un malentendu aux niveaux élevés de l'organisation quant à ce qui compte vraiment. Ce qui compte, c'est de laisser les bons codeurs faire ce dont ils ont besoin et d'utiliser les outils qui les rendent les plus confortables. IDE l'uniformité a très peu à voir avec la vraie communication qui a lieu sur les questions essentielles de l'architecture d'objet, des tests unitaires, des algorithmes, etc.
Avoir le même IDE en tant que prochain gars signifie simplement que nous savons tous les deux comment parcourir le code avec les mêmes raccourcis et comment notre compilation/configuration est mise en place. sur les vrais problèmes de code.
Regardez, c'est habitable, en fonction d'autres facteurs de l'entreprise. Vous pouvez toujours utiliser votre propre éditeur préféré pour les tâches quotidiennes. Et peut-être que votre groupe fait d'autres grandes choses qui créent une grande culture. Mais les IDE mandatés sont un énorme faux pas de l'OMI. Pour moi, si JE interviewais une entreprise et ils m'informaient qui IDE j'étais autorisé à utiliser, je les remercie poliment pour leur temps.
J'aurais le "mandat de l'entreprise" IDE installé, mais ferais toujours la plupart de mon travail dans ce que IDE je voulais - ce n'est pas comme tout le monde peut dire ce que IDE a été utilisé pour éditer un fichier source.
Sur le IDE vs éditeur avant ... pour presque toutes les langues, je fortement préfère un IDE (IntelliJ) parce qu'il y a il peut faire beaucoup plus pour vous qu'un éditeur. Il y a certaines choses pour lesquelles je reviens à ST2 ou Emacs, mais pour le codage au quotidien, malgré combien j'aime les deux ST2/Emacs, le IDE gagne presque toujours.
Dans notre Ruby il y a une forte recommandation d'utiliser le IDE la plupart de l'équipe apprécie (RubyMine), parce que nous le savons fait le travail et nous pouvons nous enseigner des raccourcis, etc.
Les développeurs sont libres d'utiliser un IDE différent, mais nous leur demandons d'avoir de solides compétences dans cet éditeur s'ils le souhaitent. Si nous voyons quelqu'un qui a du mal à naviguer dans son projet ou à modifier du texte dans son FooEdit personnalisé, RubyMine est pour lui.
Si un programmeur est un expert d'un IDE donné, il doit l'utiliser. S'ils ne sont pas experts dans aucun IDE, il y en a probablement un ou deux qui sont très courants pour votre langage de programmation ou au sein de votre équipe, et il est probablement logique pour eux de l'apprendre.
Être forcé de normaliser sur un IDE sonne comme une terrible idée.
Ceci est un énorme drapeau rouge. Chaque entreprise a quelques idées stupides, mais si d'autres drapeaux rouges continuent d'apparaître, partez.
Il est facile de perdre la motivation derrière certaines décisions - en particulier avec une équipe en croissance rapide. La motivation pour passer à Eclipse pourrait simplement être le fait que la plupart des développeurs semblent perdre beaucoup de temps à simplement configurer le IDE et qu'il n'y a qu'une expertise limitée avec votre entreprise.
Je prendrais simplement l'ordre de passer à Eclipse pour signifier que vous devriez avoir la configuration Eclipse au cas où cela serait nécessaire, mais continuez votre travail dans votre éditeur préféré. (Vous devrez peut-être passer progressivement à Eclipse si votre entreprise commence à déployer des outils sympas dans Eclipse.)
Red Flag: J'attendrais s'il y a quelques autres ordres irrationnels avant d'être inquiet.
Les raisons pour lesquelles une entreprise oblige un éditeur ou un logiciel en général à imposer à ses développeurs doivent être examinées. La partie paranoïaque (peut-être pas le mot que je recherche) pense que je pourrais ajouter une sorte de suivi de la productivité à l'Eclipse qu'ils demandent aux développeurs d'installer. Une pensée beaucoup moins paranoïaque (encore) serait qu'ils ont passé du temps à ajouter des outils de création de produit à cela IDE qui rendrait les choses beaucoup plus faciles si tout le monde appuyait sur le même bouton pour tester et construire leur branche de code .
Quoi qu'il en soit, ce que j'essaie de dire, c'est probablement plus que de la simple bureaucratie ou une méthode pour jouer avec les développeurs.
C'est sûrement une mauvaise idée. Il est inévitable que l'équipe devienne moins productive car elle doit apprendre à utiliser de nouveaux outils. Et même alors, ils ne seront pas aussi efficaces qu'avec les outils qu'ils ont déjà grok.
Depuis que j'ai essayé moi-même divers outils, j'ai toujours eu à un moment donné le sentiment "ça alors, cet éditeur me dérange avec <insérer un bug/différence par rapport à l'outil préféré>". Ce sera donc aussi un inconvénient moral.
Mais bien sûr, il y a aussi des avantages à ce que toute une équipe utilise les mêmes outils. Partage de configs, skripts, plugins et tout ce genre de choses. Ce qui ne serait pas possible avec une diversité de jeux d'outils.
D'un autre côté… ce dernier morceau ne serait pas nécessaire si tout le monde utilisait son logiciel préféré. ;)
Une startup essaie généralement de rester agile assez longtemps pour trouver un modèle d'entreprise durable. Une fois qu'il comprend la partie argent, la direction intervient pour développer l'entreprise. C'est généralement lorsque tous les premiers employés de la technologie commencent à partir, à mesure que les processus d'ingénierie se resserrent.
Comme vous le savez, vous ne savez pas ce que le code fera réellement avant de l'exécuter. Turing l'a prouvé dès les premiers jours de l'informatique. Cela signifie qu'il n'existe aucune mesure significative de la productivité lorsqu'il s'agit d'écrire des logiciels. Cependant, pour que la direction fasse son travail, la productivité doit être lisible. Puisque vous ne pouvez pas mesurer le code (et les gens ont essayé - des lignes de code, par exemple), ils mesureront ce qu'ils peuvent voir. Les programmeurs sont plus lisibles que les logiciels qu'ils développent. L'équipe de gestion typique essaie de contrôler les programmeurs afin de rendre ces choses lisibles pour eux (au lieu de faire leur vrai travail: s'écarter). Et parce qu'ils mesurent les mauvaises choses, cela ne fonctionne pas très bien.
Cela dit, vous pouvez toujours faire un long chemin avec une équipe faiblement couplée. L'équipe de développement de Github compte environ 50 personnes et ils enfreignent toutes les règles des manuels de gestion d'entreprise. Ils semblent bien se porter. Les bugs sont corrigés (éventuellement). Les fonctionnalités sont ajoutées. Les incendies s'éteignent.
Ce qui est un gros drapeau rouge, c'est s'ils essaient de faire évoluer les choses sans avoir compris comment gagner de l'argent. À ce stade, vous devez vous demander quelle est la valeur réelle de vos options et octrois non acquis.
Si vous utilisez Git et que votre branche est en panne, vous ne devriez pas avoir besoin d'utiliser les éditeurs les uns des autres de toute façon. Vous pouvez simplement pousser une branche et demander à un autre développeur de la tirer pour la faire fonctionner s'il ne peut vraiment pas comprendre votre ensemble d'outils. Forcer tout le monde à utiliser le même éditeur ressemble à une commande d'un chef d'entreprise qui veut avoir l'air intelligent mais ne comprend pas vraiment la façon dont vous travaillez.
Si vous y réfléchissez du point de vue de la gestion, la raison pour laquelle ils le font peut-être est la conformité légale. La société est responsable de s'assurer que chaque outil utilisé est utilisé légalement et n'encombrera pas non plus le produit en cours de développement. (Certains éditeurs sont gratuits pour un usage personnel, mais pas gratuits à d'autres fins, etc.) Pour auditer chaque outil que chaque développeur peut vouloir utiliser peut être coûteux. J'ai vu que sur des projets où les délais sont serrés, la direction sera prudente quant aux outils/bibliothèques/etc qui sont utilisés pour minimiser les changements plus tard dans le projet qui sont dirigés par les personnes juridiques.
Sur les projets à plus haute sécurité, il y a aussi le souci de savoir où les IDE stockent les fichiers temporaires et quelles informations sont stockées entre les sessions.
Tout dépend des raisons pour lesquelles ils doivent recommander Eclipse. Si les développeurs ont du mal à configurer leur environnement parce que tout le monde organise les choses différemment, il peut y avoir une raison de recommander une camisole de force. Si, cependant, tout le monde était heureux et productif en utilisant ce qu'il voulait, il n'y a pas de raison d'imposer un changement à quelque chose de si profondément impliqué dans le processus créatif.
Eclipse est bien plus qu'un éditeur - vous pouvez continuer à utiliser votre éditeur préféré pour éditer votre code et compter sur Eclipse pour le contrôle des sources, le débogage et tout ce que le workflow mandaté par l'entreprise souhaite qu'il utilise.
Une dernière chose - l'application du processus à ce niveau peut indiquer que l'entreprise a l'intention d'élargir l'équipe de développement et souhaite avoir un certain cadre en place afin que les nouveaux coéquipiers puissent devenir productifs plus rapidement. Si vous pensez que Rails (ou Django) est un framework "avisé", vous vous rendrez compte que la structure aide à comprendre plus facilement les nouvelles applications.
Le drapeau rouge n'est pas tant qu'un seul IDE/éditeur est imposé à chaque développeur, mais que cette décision, et en particulier la décision sur laquelle l'IDE/l'éditeur devait être utilisé, n'a pas été prise par tous les développeurs, et peut-être aucun des leur!?!
Il serait certainement préférable que les développeurs parviennent à un consensus, surtout parce qu'ils sont évidemment les mieux qualifiés pour la décision (au moins sur quel éditeur/IDE). Il peut y avoir de bonnes raisons de se conformer et cette décision devrait peser dans la préférence de la direction, mais quel éditeur/IDE aurait dû être la décision de tous les développeurs.
Il serait facile d'amener 12 développeurs à voter. Certes, il y avait suffisamment de temps pour le faire! La conclusion aurait été douloureuse pour certains de toute façon et elle aurait même pu finir par être Eclipse à la fin, mais étiqueter l'exigence comme un "drapeau rouge" dans ce cas serait beaucoup plus discutable.
Vous pouvez "utiliser" Eclipse tout en tapant SublimeText2.
Cela signifie qu'Eclipse est installé et configuré pour vos projets et se familiarise avec celui-ci afin que vous soyez également à l'aise de l'utiliser si, par exemple, la programmation en binôme. Personne ne se souciera (ou du moins ne devrait) se soucier de l'éditeur que vous avez utilisé pour taper un morceau de code que vous avez commis tant que la maintenance de votre configuration parallèle ne prend pas trop de temps et que vous ne vous coupez pas du environnement de développement standard.