Comment les managers choisissent les langages de programmation

Ce n'est un secret pour personne que les gestionnaires peuvent et souvent imposeront le langage de programmation qui sera utilisé pour un projet.

Étant moi-même programmeur, je n'ai jamais pu comprendre cela.

Mais maintenant je pense que je le fais: je viens d'avoir une révélation quand Joel Spolsky a dit sur le podcast qu'ils devraient utiliser QuickBooks parce que "chaque comptable dans le monde le sait". Cela m'a semblé très similaire à «j'ai choisi Java parce que tous les programmeurs du monde le savent».

Maintenant que j'ai vu le même problème d'un autre point de vue, je ne connais pas grand-chose à la comptabilité, mais je sais quelque chose sur la programmation, je me demande comment un programmeur peut aider à s'assurer que le bon langage de programmation est choisi pour un projet ?

L'erreur de nombreux programmeurs est qu'ils vont argumenter le point (ou simplement être d'accord ou en désaccord avec lui) basé uniquement sur le mérite technique. Avec la direction - et l'entreprise dans son ensemble - vous devez d'abord discuter de l'analyse de rentabilisation et des mérites de l'entreprise et des mérites techniques.

Cela va au-delà du choix du langage de programmation et imprègne pratiquement toutes les décisions techniques.

Permettez-moi de vous donner un exemple: les PC. Joel soutient (correctement) que les développeurs devraient avoir des machines de premier ordre car le temps de développement est cher. En cela, il a parfaitement raison. Mais comment argumentez-vous cela? Simple:

Exemple: je fais une compilation du code environ 20 fois par jour. Chaque fois, cela prend 3 minutes. Si j'avais un PC rapide, je pourrais le construire en 1,5 minute. Donc, pour 1000 $ supplémentaires tous les deux ans, je peux obtenir une demi-heure supplémentaire par jour, ce qui pour un programmeur gagnant 100000 $ (avec des coûts supplémentaires d'au moins 50%), ce qui équivaut à environ 10000 $ par an de temps.

Mais argumenter à l'autre extrémité est que les RH décident d'une taille unique en ce qui concerne les politiques et les PC, de sorte qu'un employé du centre d'appels gagnant 25000 $ et un programmeur gagnant quatre fois qui devraient pour une raison quelconque avoir le même PC.

La plate-forme technologique et les langues auront de nombreux facteurs à prendre en compte dans le processus décisionnel:

• Relation stratégique avec des fournisseurs particuliers. Si votre entreprise est un partenaire Microsoft Gold (ou quelque chose comme ça maintenant), alors bonne chance pour Java ou Python;
• Le département informatique soutenant une configuration particulière parce que l'argent pour les PC provient de leur budget;
• Le service informatique décidant que tout le monde devrait exécuter Windows 2000 car il n'y a pas de personnes exécutant Linux;
• Quels autres systèmes l'entreprise possède déjà (par exemple, s'ils utilisent Java pour tout le reste, il est logique de l'utiliser pour cela même si en soi ce n'est peut-être pas le meilleur choix);
• Aversion au risque pour différentes plateformes ou langues simplement par manque d'expérience;
• Plus intéressé à discuter du risque avec la haute direction qu'à faire plaisir aux développeurs;
• Certains gestionnaires prennent les décisions qu'ils prennent simplement parce que leurs mains sont liées;
• Des raisons budgétaires, bien que cela puisse aussi jouer en votre faveur, car cela empêche les fous coûteux de votre maison comme le PVCS, tout ce qui est produit par Rational, etc.
• Aversion du service juridique pour les licences open source;
• Ne pas impliquer le personnel technique dans la planification et l'estimation du projet;
• Familiarité de la part du manager avec une plate-forme particulière (les techniciens en sont aussi coupables mais dans les deux cas ce n'est pas forcément une mauvaise chose - avec de nombreux outils qui peuvent mieux faire le boulot du diable que vous connaissez).
• Expérience du personnel technique. S'ils sont tous issus de C #, pourquoi utiliseraient-ils Java, Python ou Ruby?
• De nombreuses autres raisons

Quel que soit le cas, vous devez comprendre la raison (et je vous garantis qu'il y en aura plusieurs) et argumenter sur le fond en ces termes. Certains programmeurs sont assez naïfs dans ce département et semblent penser que de telles décisions sont prises par ignorance ou même vindicatif alors que presque toujours de nombreux facteurs sont en jeu.

D'après ce que j'ai l'air dans mon entreprise: lorsque les gestionnaires choisissent un langage de programmation, ils le font généralement de manière très conservatrice - en tenant compte du type de compétences en programmation actuellement disponibles dans l'équipe (et s'il serait facile d'en embaucher facilement d'autres) ), qu'il s'agisse d'une langue bien établie, en essayant de choisir quelque chose qui s'adaptera à l'infrastructure actuelle et ne fera pas de gros efforts pour l'adapter à ce qui existe déjà. Lorsque les programmeurs choisissent un langage de programmation, les choses ont souvent tendance à être un peu différentes - ils aiment souvent relever un nouveau défi et aimeraient se familiariser avec la dernière tendance tendance et choisir quelque chose où ils peuvent apprendre de nouvelles choses.

Idéalement, tout se résume à discuter des avantages et des inconvénients entre le gestionnaire et l'équipe de développement et à trouver la solution qui convient le mieux au problème. Cela implique généralement beaucoup de discussions et de convaincre :-)

Réponse tardive, mais comme il n'y a pas encore de réponse acceptée, je vais essayer. Je considère cela comme deux questions et j'essaierai d'y répondre séparément:

Comment les managers choisissent-ils les langages de programmation?

Cela dépend fortement de la taille de l'organisation et de l'expérience du gestionnaire, mais impliquera généralement d'évaluer la situation actuelle et les scénarios et exigences futurs. Cela se fait généralement via PESTLE ou une analyse similaire, et juste pour donner quelques échantillons dans chaque catégorie:

• Politique
  • "Personne n'a été licencié pour avoir acheté IBM" - un choix sûr.
  • Le PDG a entendu que Java est cool - battage médiatique.
  • L'architecte en chef aime .NET - projet pour animaux de compagnie.
  • Le langage est contrôlé par un concurrent hostile - pourquoi Google ne s'appuie pas sur C #.
• Économique
  • Coûts de licence.
  • Coût de la formation des développeurs.
  • Coûts de migration de la base de code.
• Social
  • Adhésion de l'équipe.
  • Disponibilité des compétences en interne (besoins de formation, continuité).
  • Disponibilité des compétences sur le marché.
  • Menace pour le statu quo existant au sein de l'équipe de développement.
  • Disponibilité d'une communauté de pratique suffisamment grande.
• Technologique
  • Amélioration de la productivité.
  • Amelioration de la qualite.
  • Capacité à interagir avec la base de code existante.
  • Respect des normes.
  • Maturité.
• Légal
  • Conditions de licence.
  • Contrôle de la technologie (Qui possède et contrôle la technologie? Quelle sera la future stratégie d'octroi de licences?)
  • Conformité légale et réglementaire.
• Environnement
  • Infrastructure existante au sein de l'entreprise.
  • Compétences existantes au sein de l'entreprise.
  • Intégration avec des partenaires externes.
  • Niveau de support technologique par un environnement plus large.

Ensuite, un groupe de langues correspondant aux critères peut être évalué plus à fond en utilisant l' analyse SWOT , l' analyse coûts- avantages ou similaire.

L'ensemble du processus peut être assez complexe, mais en fin de compte, la plupart des entreprises ou des équipes de projet opteront pour l'option la plus sûre compte tenu de leur situation actuelle qui peut toujours fournir les capacités dont elles ont besoin. Très souvent, cela peut signifier de rester plus longtemps sur la plate-forme actuelle.

Comment un programmeur peut-il s'assurer que le bon langage de programmation est choisi pour un projet

Comme il a été, espérons-le, démontré qu'un programmeur type aurait normalement seulement 1 / 6e de la contribution totale au processus de prise de décision. Et en règle générale, elle ou il serait surtout intéressé par les seules capacités linguistiques!

Eh bien, la meilleure façon d'influencer la décision semble avoir une image plus large du processus de sélection, faire des alliés à l'intérieur et à l'extérieur de l'équipe, créer un bon dossier sur l'aspect technologique des choses et essayer de ne pas se concentrer uniquement sur les capacités linguistiques.

Et, bien sûr, il faut se mettre en position lorsqu'un gestionnaire de projet ou de développement (ou toute autre personne en charge) voit les avantages de passer par l'ensemble du processus d'évaluation et est prêt à considérer les risques et les incertitudes de passer à un autre langue en premier lieu. Pour que cela se produise, il faut démontrer que:

1. La plate-forme actuelle n'est plus adéquate.
2. Une nouvelle plateforme promet des avantages qui dépassent de loin les tracas.

Cependant, auriez-vous demandé "Quelle est la meilleure façon d'utiliser au travail la langue que j'aime", la réponse aurait probablement été "rejoindre une entreprise qui utilise déjà la langue ou créer la vôtre".

Le gestionnaire A se rend dans une retraite d'été où il rencontre le gestionnaire B.

R: Quelle langue utilisez-vous dans votre entreprise? B: Oh, nous utilisons CA Visual Objects, cela rend les drones beaucoup plus productifs que COBOL.

Et c'est ainsi que la décision a été prise. Fin de l'histoire vraie.

Chaque plate-forme a ses bons et ses mauvais côtés. .NET est cool et puissant mais vous êtes à peu près coincé avec les serveurs Windows. Le rubis est cool mais lent. Il serait difficile de trouver des développeurs pour Haskell.

Le fait est que le langage n'affecte pas la rapidité du projet et la beauté du code, mais aussi les choses qui intéressent les gestionnaires. Donc, si vous voulez les influencer, vous devriez maintenant leurs préférences et trouver autant de bons côtés dans leur perspective que possible.

En séparant les préoccupations. Les entreprises doivent être en charge des décisions commerciales et la technologie en charge des décisions technologiques. J'aime le terme «responsabilité acceptée». Si j'accepte la responsabilité, j'exige également que je puisse faire les choix qui concernent mon domaine de problème. Le business me donne, ainsi qu'à mes collègues tech, les exigences du business et nous répondons avec une ou deux alternatives sur la façon dont nous pouvons accepter la responsabilité de livrer. Cela ne devrait jamais être comme "nous le ferons en Python ou en C #". Plutôt;

«Nous pouvons accepter deux responsabilités différentes ici: si nous procédons de cette façon, nous pouvons livrer cela rapidement et nous répondons très bien à ces exigences commerciales et celles-ci sont un peu plus difficiles. . La variante A appelle à ces ressources et la variante B signifie que nous devons également faire ceci et cela ... "

Ensuite, les entreprises choisissent, mais notez que les entreprises choisissent en fonction de leur impact sur les choses commerciales et non techniques. Et ils n'ont pas le choix entre des alternatives où la technologie n'est pas prête à accepter la responsabilité de la partie technique.

Devenez le manager. (sourire)

Sérieusement, il vous suffit de discuter de la question avec le décideur en question et de présenter vos arguments. S'ils choisissent de s'en tenir à une décision vraiment erronée, leur compétence générale n'est probablement pas si chaude et il vaut peut-être la peine de chercher autre chose à faire.

Je pense que la différence entre ce dont vous parlez et ce dont parlait Joel est que la programmation est une compétence de base alors que la comptabilité ne l'est pas. Le point en utilisant Quickbooks est, sans doute, parce que vous n'êtes pas un comptable et les comptables peuvent vous aider avec cela. Cependant, si la programmation est votre compétence de base, et probablement si vous êtes un programmeur, les règles du jeu sont un peu différentes.

Cela dépend beaucoup de la personnalité du manager:

Il y a ceux qui préfèrent les mots à la mode. Découvrez simplement quels mots à la mode ils aiment et utilisez-les lorsque vous lui parlez en conjonction avec la langue que vous souhaitez utiliser.

D'autres ne feront confiance qu'à des choses qu'ils connaissent eux-mêmes (comme VB 6.0 par exemple). Rendez leur langue de choix facile à comprendre pour eux («vous savez, c'est comme dans le bon vieux VB» - même si vous parlez de Haskell ...)

Mais en réalité, la plupart des managers ne sont pas aussi stupides que nous le pensons les geeks, et ils peuvent être raisonnés. Ce qui est important ici, c'est que vous compreniez leur point de vue: ils ne se soucient généralement pas des détails techniques spécifiques, ils se soucient des résultats. Alors ne leur dites pas que .net ou Java ou Delphi ou quoi que ce soit qui a cette formidable fonctionnalité megacool. Dites-leur que (entrez votre langue ici) est un bon choix car la fonctionnalité A réduit les temps de développement dans un projet comme celui-ci, ou cette fonctionnalité B réduit les bogues et raccourcit donc le temps nécessaire pour les tests. Assurez-vous simplement que votre argument est valable, ne lui mentez pas.

En d'autres termes: traitez-le comme un être intelligent (il l'est probablement).

Pensez à la langue qu'on vous demande d'utiliser très très fort. Assurez-vous que vous savez que ce n'est pas une bonne langue pour le travail, puis demandez au gestionnaire si vous pourriez faire une suggestion quant à une autre meilleure langue à utiliser pour le travail. Fournissez toutes les informations que vous pouvez prouver que la langue ne serait pas bonne pour le travail et voyez ce qu'il dit. Ça ne peut pas faire de mal. :)

Le choix du langage de programmation est souvent une décision commerciale. Les clients / utilisateurs s'en moquent. Voici une courte citation (de http://www.ericsink.com/bos/Geeks_Rule.html ):

Les langages de programmation sont choisis principalement pour des raisons commerciales. Je passe la plupart de mon temps à travailler avec des langues que je n'aime pas vraiment, car les langues avec lesquelles j'aimerais travailler présentent des inconvénients commerciaux qui l'emportent sur leurs mérites techniques. Voilà la nature du jeu. Je peux accepter la situation (mon choix) ou trouver un nouvel employeur. Se plaindre de la façon dont je ne peux pas utiliser Java ou Python ou quoi que ce soit au travail n'est tout simplement pas une option.

Tout d'abord, la programmation est une autre forme d'art. Une forme d'art très logique. Si votre manager est passionné par ses projets logiciels extraordinaires, qui sont dans une certaine mesure, des œuvres de chef-d'œuvre, demandez à ce gestionnaire passionné ce qui suit:

Combien d' énergie et le temps que cela coûterait Rembrandt supplémentaire de ne pas peindre avec son pinceau préféré, mais une brosse qui, après un examen attentif de l'équipe de direction, est remis à lui, il y a 400 ans et avant ses œuvres de devenir célèbre. Sa peinture va-t-elle plus ou moins valoir la peine?

De même, si vous dites à un programmeur quel langage doit être utilisé, alors soyez cohérent et dites également à un peintre quelles tailles de pinceau doivent être utilisées! OU, sinon, laissez ce choix aux gens qui ont besoin de travailler avec lui tous les jours et (comme la plupart des chefs-d'œuvre) la nuit!

Ce sont des concepts différents.

Lors de la comptabilité, vous partagez vos résultats: pour les impôts, la loi, les investisseurs, etc. Ils ont besoin d'un outil pour voir le résultat de votre travail, et cet outil doit être bien connu.

Lors de la programmation, vous utilisez n'importe quel outil de votre choix - tant qu'il génère un .exefichier que vous pouvez exécuter sous Windows. C'est exactement la même chose qu'un document lisible Quick Books en cas de comptabilité.

Donc, si vous développez un grille-pain, vous êtes libre de conserver votre documentation interne en chinois, mais vous feriez mieux de fournir un manuel en anglais.

Il y a encore une chose: si les règles de votre entreprise supposent que le résultat de votre code n'est pas un produit lui-même, mais un code source pour lui, alors à coup sûr, ils peuvent décider à quoi il ressemblera (en choisissant la langue qu'ils souhaitent).

Ce qu'ils choisissent dépend de leurs objectifs: s'ils veulent des programmeurs facilement remplaçables, ils choisissent Java; s'ils l'envoient à un autre service, ce sera l'exigence de ce service, etc.

D'après mon expérience, cela dépend toujours de:

1. Avons-nous les ressources pour utiliser la langue?
2. Avons-nous les ressources pour maintenir la langue?
3. Si nous n'avons pas les ressources nécessaires pour utiliser et maintenir la langue, combien est-il difficile / coûteux d'obtenir ces ressources?
4. Quel est le "futur" de la langue (va-t-elle être présente et utilisée pendant un certain temps?)

À moins que le projet n'ait besoin de quelque chose que seul un langage / une plate-forme / une technologie / un cadre spécifique fournit, il se résume à ce que nous savons et utilisons déjà. L'embauche de nouvelles personnes et la formation de programmeurs existants coûtent assez cher à la plupart des entreprises. Lors de l'embauche, nous considérons toujours la langue et nous assurons que les candidats savent quelle (s) langue (s) ils utiliseront probablement.

J'espère que vous avez un programmeur qui est également un gestionnaire et qui peut représenter les programmeurs dans ces types de décisions. Si ce n'est pas le cas, c'est une situation dangereuse et vous devriez en parler avec votre responsable si vous savez qu'une telle décision est en train d'être prise.