我刚刚与我的一名员工讨论了部门编程语言标准。他认为，编程语言的选择应由项目团队负责。我觉得管理层应该对使用哪种语言有整体的决定。如果两种语言符合项目标准，是否应考虑团队的需求？我很想听听每个人的经验。

解决方案

我认为，如果团队成员说"我们想使用这种语言"，他们的士气将遭受极大的打击。管理层说"不，我们必须改用这种语言。"

这确实是一个共同的决定，每个人都需要支持其推理。

是的。
两组都应有输入。
尽管可能是一个重要的方面，但许多其他方面也需要被优先考虑。就业市场(雇用新员工的能力)，语言支持，工具等。

我们必须考虑团队，他们将成为团队的成员。如果他们不能使用该语言，那将使完成该项目非常困难。

显然，管理层将拥有最后的发言权，这就是管理层的目的，但是他们必须考虑团队的偏好/建议。我认为他们必须有充分的理由不选择团队建议的语言

如果程序员比Java更擅长Java，那么，如果其中任何一个都能工作，则使用Java是有意义的。与该级别的任何决定一样，管理层可能有理由选择一个或者另一个。他们应该听取团队的意见，但是最终的决定应该是他们的。

我觉得开发人员确实应该在所选语言中有发言权。总体而言，管理者似乎习惯于使用"流行语"。 (良好)程序员将有望了解该工作的最佳语言，这是基于管理层可能缺乏的多年经验得出的意见。

请记住，如果/当编程团队继续前进时，管理层必须保留代码，将来他们还需要聘请新的编码人员来维护它。因此，如果团队想要选择erlang或者haskell，则管理层有责任对公司说不。 (很抱歉选择erlang和haskell开发人员，但是你们当中的人并不多。)

通常，这是团队希望使用某种以某种方式使他们受益的问题，但是重点应该放在代码的未来上，该代码属于公司并由公司支付(即工资)。他们需要确保其将来可支持。

他们也将为培训付费，因此这很大程度上取决于管理层。

团队可以提出建议，并尝试影响决策，我敢肯定，除了最糟糕的公司以外，所有公司都会认真听取团队的意见，但最终还是要听管理层的决定。

当然，团队的投入很重要。如果我们决定应用程序的主要架构部分，并且团队认为他们没有参与其中，那么我们将遇到道德问题。该决定最终应由管理层(假设管理本质上是技术)以及首席架构师和项目经理来做出。

但是选择一种语言时要记住的一件事是，当团队对选择更加熟悉和满意时，成功率就会更高。如果我们听取他们的意见，然后带着具体的业务和技术原因与他们接触，为什么我们不选择他们，那么至少他们会觉得自己是在撒谎，他们是他们的一部分，并且是过程的一部分。

与生活中的大多数事情一样，必须在对个人(每个团队成员)或者对组织(应该是管理者的重点)的好处/乐趣之间达到平衡。

根据我在工作场所的经验，管理层与技术团队进行了讨论，技术团队就我们熟悉且最擅长使用的编程语言提出了建议。然后，管理层决定部门使用的编程语言。
它应该双向工作，因为技术团队必须熟悉编程语言(以便能够按时交付)，并且对于管理人员，他们可以为业务，资源管理和培训制定中长期计划。

团队对此毫无疑问，

一个好的项目经理将让他的高级工程师做出决定并完成他的工作：管理项目，即使开发团队免受"高层管理BS"的影响。一个好的项目经理还需要他的高级工程师详细说明为什么他们选择一种特定的编程语言(如果语言的选择非常重要)。如果他对理由不满意，我认为引导开发团队朝着每个人都可以生活和工作的方向发展是他/她的工作。强迫开发团队使用某种语言？这不是一个好主意。该项目注定要失败。

我认为，这在很大程度上取决于情况。

当然，我们应该考虑到他们的愿望，但是要考虑的一大问题是团队将使用哪种语言来提高生产力。另外，有时会被忽视的一个重要因素是，谁将长期维护项目并他们的能力是什么？

对我来说，最后一个是相当大的一个，程序员经常会在某些奇怪的情况下采用某些边缘案例技术，这主要是因为他/她想"尝试一下"或者因为它是新的而又热门。在那种情况下，可维护性常常被人们遗忘，一旦程序员走了而其他人不得不承担项目的维护工作，这就会再次咬伤公司。

另一方面，如果团队对此感到非常强烈，是否值得引起裂痕？

因此，归根结底，这取决于情况以及它是什么类型的项目。

我认为两种方法都存在危险。程序员可能倾向于使用凉爽而有趣的新技术，而管理则可能与大量销售或者商业化的技术一起使用(但在反微软开发团队中并不受欢迎；)。

需要有人担任架构师角色，可以与两个团队保持联系，并根据业务目标和开发人员的关注做出客观的决定。这个人需要了解系统的总体目标，权衡客户所需的基础架构，健壮性和对技术的支持。等等...当然，这确实取决于公司/项目的规模以及这些决策的影响。

同意其他海报，这应该是一个共同的决定。但是通常，管理人员必须要比项目团队有更长远的眼光，例如正在进行的维护工作。因此，软件的寿命可能是一个因素。如果团队选择的东西不是主流，那么他们总是会费尽心机。

此外，最终决定权通常属于客户。如果项目在内部，则客户可能只是本地管理/技术人员。对于其他客户，团队将需要一些非常有说服力的理由来推翻他们的意愿。

真正的问题是选择一种语言而不是另一种语言有什么好处：

• 功能性：现在和将来，什么可以使工作做得更好？这项技术决定是否会证明该项目未来的坚如磐石的决定，我什至会对此予以关注(当然，从管理层的角度来看)？
• 成本：我是否需要购买其他硬件或者软件以进行此技术选择？我要坚持使用该硬件/软件吗？是建议开发人员精通这项技术，还是我必须雇用新人？
• 时间：使用这项技术需要花费多少时间？我需要训练人们使用它吗？

事实是，管理层应该问这些问题，而发展应该是它们的良方。

对不起，但是在工程的其他哪个领域，这还是个问题吗？
波音公司的设计师们决定使用火箭发动机而不是涡轮风扇会更凉爽吗？

这实际上是变相的"信任"问题。

当管理人员信任时，选择就变得轻而易举(由技术专家决定)。

我建议任何正在经历这种情况的团队都应研究潜在的信任问题，而不是仅仅关注语言问题。

着重于根本原因，结果/症状将自行解决。

我们首先要考虑的是语言是否能胜任。马克·吐温(Mark Twain)说："对于一个拿着锤子的人来说，一切都像钉子。"因此，仅仅因为团队熟悉一种语言，并不意味着它是最好的工具。另一方面，使用某种语言并具有丰富经验的开发人员和领域专家可以使用自己的工具来提高生产力。

第二个问题是开发人员的可用性。当团队继续前进时，剩下谁来支持它？雇用或者培训晦涩的语言可能会很昂贵。该语言可能还不够新，以至于开发人员基础可能无法实现。

第三个问题是工具的可用性/稳定性。我们是否需要在每次语言更改时进行不断的重写(我在考虑VB / .Net)。另外，谁在支持它？如果供应商放弃使用该语言，该怎么办？

简短的答案是，如果团队有偏好，他们应该提出强有力的选择依据。令人信服的足以说服老板，推销员的回扣不值得麻烦。尝试了解管理层的理由，以便我们可以接受决定(如果我们无法驳斥它)。

项目语言的选择应包括团队的偏好，而不是覆盖项目及其环境的正确选择。

编程团队应该比管理团队在入围语言方面有更多的经验，因为这是他们被聘用的语言，并且应该具有更好的技术资格，以判断哪种技术更适合他们使用。

只有管​​理团队至少在选择方面具有足够的资格和经验，他们才可以尝试影响团队的协作选择，除非这些选择不涉及任何技术上的业务影响，应提出这些考虑。

良好的管理让员工来做是他们雇用他们做的事，并尽其所能尽职尽责，因此恕我直言，应将选择权委托给编程团队。

一个快乐的编程团队将提高工作效率，得到更好的结果，并且如果他们在选择方面遇到困难，也不会抱怨。

管理层应更关注最终项目的完成时间，预算范围内，以及积极的结果，然后再使用哪种技术，除非这些选择具有特定的业务影响需要解决。

编程团队成员和管理团队成员都在同一个团队中，应考虑每个人的需求，包括编程团队成员最舒适使用的技术以及认为对每个项目都是最佳的技术，恕我直言，这应该是首要考虑因素根据业务需求或者实际的技术考虑。

仅仅为了证明不支持编程团队选择的有效商业原因可能就是该技术不够主流，以至于无法以合理的成本从合理规模的资源库或者易于与当前或者计划资源的接口替换团队成员。

最终，这仅是管理层的选择，因为如果程序员离开，他们将承担后果的负担，并代表公司在选择中的利益。语言选择不仅必须考虑当前编程团队的能力/技能，还必须考虑所有未来成员和任何支持人员的可销售技能。如果我们不想找到一门难解的语言，那意味着我们找不到合适的人来支持它。此外，如果该语言即将流行或者受支持的寿命即将结束，则存在过时的风险，即需要比期望的更快地重写它。

我做出一个广泛的假设，即语言选择的可维护性，功能和类型没有根本不同(即ML与C ++)。

综上所述，如果牢记这些因素，并且在语言选择上处于平等地位，那么使用团队的语言选择将最能鼓舞士气，并且可以在不影响公司长期前景的情况下提供更好的产品。应用。

考虑语言。如果这是一个很容易填补的编程职位(也就是说，如果我们可以在一周内雇用某个人来填补其中一名程序员的工作，如果他们离开的话)，那么请遵循团队的建议。如果我们给他们这么多话语，我们将不会相信他们会做多少工作。否则，我们可能需要填补多个职位。不要押注经济不景气，而让软件开发人员留在自己的座位上。实际上，这是货比三家的理想时机。让他们开心，但要确保语言选择不是晦涩难懂的语言。

我肯定会与当时进行开发的团队协商。给他们设计文件并获得他们的反馈。至少这使他们觉得自己的决定很重要。

经理需要考虑其他因素，例如，用所选语言培训人员的成本，购买IDE的成本(如果需要)，在初始开发完成后维护代码库的成本。

在经理做出了明智的决定后，开发人员应该感到能够询问为什么做出特定决定。将决策留给管理层，但可以提高决策的透明度。

这个问题有很多。最后，为工作付费的人做出选择。但：

• 除非管理层比他们雇用的人更擅长编码，否则他们应该考虑他们的投入。管理层通常不会向编码人员说明每种语言选择都会产生费用，这可能会使其他选择更为可取。当编码人员感到自己的建议被忽略时，这会激起他们的怨恨。
• 有相当多的人的判断有严重缺陷。他们只知道一种语言，因此只推荐一种。管理层可能已经下定决心，将忽略它对员工的好建议。编码人员或者管理人员可能是过多的技术爱好者，即使他们不符合项目的最大利益，他们也会接受技术解决方案。他们可能也有很强的见解，没有足够的情感成熟度以至于其他人不同意。
• 员工也可能故意提出不符合项目所有者最大利益的建议，因为他们提出的建议符合他们自己的最大利益。

大多数情况下，我认为做出这些选择是出于情感原因，而不是理性的原因。

有趣的是，编程语言的选择对于管理来说应该是一个如此重要的问题，而依赖精心设计的开源库或者框架通常会在没有太多考虑的情况下进行。

从历史上看，这是有逻辑的，因为更改编程语言意味着更改平台，但是现在，编程语言已经标准化，可以在CLR或者JVM平台上运行，共享库和部署环境，因此多样化使用不同语言的成本可以小于依赖复杂框架的情况。

例如，如果应用程序需要规则引擎，则使用JVM版本的prolog可能比依赖某些晦涩的Java规则引擎API更好。