我目前工作的组织似乎正朝着向软件开发人员规定必须使用哪些工具、语言、框架等的方向前进。然而，没有人让我相信这是一件好事。我听到的主要论点是它会使培训更容易。但是，在开发软件 10 多年之后，我从来没有依靠培训来学习如何使用 IDE、编程语言或其他任何东西。所以我无法联系。
随着技术的快速发展，而我知道标准适应的速度很慢，我担心我的客户会有我无法轻松实施或无法高效实施的要求我应该这样做。例如，如果 Web 应用程序中有自动完成功能的 UI 要求，但尚未批准任何 API，我需要自己实现自动完成功能，而不是使用提供的众多 API 之一它开箱即用。
一个更激进的例子是，如果我的客户想要拥有 Google Wave 功能。在这种情况下，我希望能够灵活地配置我的开发环境（包括 IDE）并选择合适的框架（例如：GWT）来使用。
请提供反馈，说明您是否认为软件开发工具、语言等应该标准化，并提供几点支持您的论点。
标准化有很多好处。我的组织对我们将使用的技术制定了公平的标准。我们在以下领域实现了强大的优势......
招聘。很容易描述我们正在寻找什么技术，并确保我们的招聘人员正在寻找合适的人。
许可/软件成本。我可以轻松购买企业许可证。它让我有机会通过让我在少数供应商上花更多的钱来降低成本，从而获得更多的影响力。
交付的一致性。我们的团队非常了解构建、推出和维护项目需要哪些项目，因为他们之前已经成功完成（而且他们也知道其中的陷阱）。
敏捷。由于标准化，我可以更轻松地让一个团队接管另一个团队或一个人接管另一个团队。
质量。我们有跨团队的同行评审以及跨团队的质量保证。
如果没有一致地使用技术堆栈、工具、语言和框架，这些类型的好处将更难以实现。我并不排斥新技术，但除了“如果我想……怎么办”之外，还必须有一个具体的理由
我曾经为一位经理工作，他觉得需要在他的软件开发运营的各个层面进行创新。每个开发工具都必须是最先进的（最好是测试版）。他要求我们使用的许多工具都没有很好的文档，也没有培训。最终，我们尝试的大多数技术根本不起作用。我们在新技术上浪费了很多时间，但在很明显我们无法取得进展时才放弃它们。
我试图证明创新在你的价值主张所在的领域是完美的。在标准技术失败的情况下，也可以明智地使用创新。但对于大多数平凡的任务，使用久经考验的工具和方法应该是默认设置。更少的风险、更少的成本、更少的管理关注。因此，您可以将时间和精力集中在创新最受益的领域。
所以我认为标准化具有重要作用。但是盲目地说一切都必须是标准的，就像我的经理认为一切都必须创新一样肯定会失败。
标准化的一个主要问题是，一旦标准出现，它们就会被打上具体的烙印并且很难改变。这就是为什么我们的企业 IT 环境卡在 IE 6 上，而我们可以访问的最好的变更控制系统是 CVS。在这种情况下，一些开发人员打破了规则，一些开发人员在更具创新性的公司找到了工作。
你有一个混合袋在这里。
我不会对 IDE 进行标准化，因为每个开发人员的工作方式都不同。如果被迫使用 Visual Studio，那些精通 emacs 的人可能会发现他们的性能会受到影响。我使用 30 英寸显示器优化了我的 Visual Studio 体验，发现它非常高效。
然而，标准化一些工具，例如 SCons 或 make 或其他东西来构建产品是完全合理的。
禁止一些图书馆并有一个新图书馆被批准或不批准的流程也是非常合理的。我知道很多公司禁止 boost、JQuery 或一般禁止开源库等。他们有充分的理由这样做。我知道当一名实习生将他在互联网上找到的一些随机“安全”库合并到没有任何人运行的情况下时，我感到非常沮丧。
最后每家公司都不一样。您必须足够标准化，以避免随着人们来来去去或新产品的形成和组织结构的变化而出现严重的并发症和问题。但是你必须足够灵活，以避免重新发明你需要的每一个轮子。
重要的是有明确的理由采用某种工具或禁止其他工具或库。在没有咨询工程团队并出于充分理由做出决定的情况下，您不能让管理层要求您使用这个而不是那个。一旦做出决定，这些原因应该被写下来并清楚地传达。
而且，如果最终没有采用您最喜欢的工具或库，请不要抱怨。适应并做好你的工作，或者找到一个让你更快乐的新工作。
标准化的一个令人不快的后果是它往往会扼杀创新。
创新是可怕的。它涉及成本和风险。
标准化并不可怕。它在短期内降低了成本和风险。直到您的竞争对手创造了改变游戏规则的创新。那么标准化是非常昂贵的。
支持标准化的第一个论点是，它最大限度地提高了整个组织使用公共知识体系的能力。不知道如何在 ASP.NET/C# 中构建自定义 Web 控件？问问楼下的比尔，谁有知识。如果你使用不同的工具，这种组织智慧就会被打断。虽然限制在最小公分母上是不好的（希望您的管理层会意识到这一点），但您不应忽视共享经验的好处！
更新：我不同意创新和标准化是截然相反的。事实上，如果我们仍然拥有 1980 年代网络标准的混杂特征，我们是否会拥有接近网络创新的水平？不，我们不会。当然，我们可能会在新的低级网络协议上进行更多创新，但这真的值得吗？取而代之的是，我们在 TCP/IP 和 Web 标准（http、html 等）的范围内实现了创造力的爆炸式增长。
诀窍是知道如何标准化而不用它作为关闭所有新探索的论据。例如，我们在公司中仅使用 ASP.NET/C#/SQL Server，但我完全愿意在此框架内使用新工具（例如，我们最近采用了 DevExpress 报告包，取代了早期的标准）。
无论您是为内部客户开发运营软件，还是为外部客户开发产品，都没有理由不进行标准化。你当然没有给。如果您看到公司如何努力将已经维护了 10 年或更长时间的异构产品结合在一起，并且现在是开发人员在某些时候认为有意义的各种技术的集合体，那么您就不会问这个问题了。
从我的脑海中，我可以说出至少 2 家知名的软件公司，它们将被淘汰，因为它们的维护成本已经变得如此之高，以至于它们无法再竞争（但我不会）。
我认为这里的误解是压制个人主义会压制创新。那明显是错的。抑制创新的是糟糕的技术领导力。
标准化对于高效的开发团队来说是必须的。但是，这并不意味着您不能不时修改标准以使其适应新技术和趋势。
这取决于我认为的组织。像微软这样的，是的，应该有一点标准。一家只有一个 IT 部门的小企业，没有。一家在世界各地设有多个办事处的大型企业……也许吧。
这一切都取决于:-P
标准化有几个很好的理由。
首先，如果每个人都或多或少熟悉相同的事物，它可以让企业获得更好的组织灵活性。它还允许人们更好地互相帮助。对于 ASP.NET 方面的问题，我无能为力，而且在 C++ 方面能帮助我的人并不多。
其次，它减少了支持问题和费用。Oracle 和 SQL Server 都是不错的产品，但将两者用于类似的功能只会导致问题。更不用说我在商店里使用几个完全不同的平台来做类似的事情，这并不有趣。
第三，有些东西必须标准化。我们无法使用 VS 2005 和 VS 2008 操作一半，因为我们将项目文件置于源代码控制之下。我们必须选择一个时间并转换。
第四，在一些业务中，它简化了监管问题。我不知道你在做什么生意一切都在以一种标准的方式进行。
第五，如果您正在处理需要花钱的软件，它可以简化采购。
这并没有特别限制我们，因为如果我们需要的东西不是标准化的，我们就继续去做或者去做。
如果你想提出一个反对标准化的商业案例，你需要有一个与商业相关的论据。您的论点似乎是您将无法实现用户想要的功能，这是一个考虑因素。有另一个论点？
我工作的公司使用 C#、ASP.NET、JavaScript 并生成 HTML。超越上述优点的优点在于，可以感觉到维护和自适应变化的速度有所提高。缺点包括让那些精通技术（极客）并且更喜欢使用混合和匹配语言的人产生一些无聊，这取决于他们认为更适合什么，或者出于“性能原因”。
当您尽可能快地开发以满足紧迫的最后期限并在高度饱和的 Web 开发市场中竞争时，技术和个人监督总是很好的。
假设该组织有一套广泛的企业应用程序要管理，我会拒绝，原因如下，尽管我可能过于从字面上理解了一切都相同的信息：
对使用最佳系统的妥协，例如，如果所有数据库都是 MS-SQL，那么任何 Oracle DB 解决方案都将被抛弃。这也适用于每个使用 IDE 的人都必须使用相同的事实，无论他们是在进行数据仓库报告开发、Web 应用程序、控制台应用程序还是 winForms。我正在考虑诸如 ERP、CRM、SCM、CMS、SSO 和各种其他 TLA、FLA 和 SLA 之类的系统。（LA = 解码提示的字母首字母缩写词，如果需要）
委员会升级是另一个有趣的问题。如果每个团队都可以选择他们的工具并让一个人决定升级，例如开始使用 Visual Studio 2008 而不是 Visual Studio 2005，那么现在必须确定在什么阈值上同时升级每个人是值得的，这可能是如果有多个开发人员，那就很头疼了。比如过去 10 年什么时候会有 IDE 变化、框架变化等等？
标准的例外情况。如果承包商认为它可以帮助他们构建更好的软件，例如 Resharper 或其他一些承包商认为非常值得而组织不想花钱购买的附加组件，他们是否可以带来组织中未使用的东西？遗留系统可能会使标准变得有点笨拙，例如这是在 ASP.Net 1.1 中构建的，因此每个人都必须安装 VS 2003，即使大多数人永远不会使用它？
只是我对此的想法。
对足够丰富的 IDE 进行标准化以供个人开发人员配置并没有错。
但是，请确保您不会阻止个别开发人员使用其他工具，只要这些工具获得许可，并且一个开发人员使用该工具不需要所有其他开发人员都使用它。
例如，我碰巧使用NORMA来帮助我设计数据库。输出是 SQL Server DDL（或我想要的任何其他内容）。我可以让 DDL 成为项目的一部分，而无需让我的 NORMA 源成为项目的一部分。以后的开发人员不需要使用 NORMA 来处理项目。
另一方面，如果我决定使用配置部分设计器来创建配置部分，那么未来的开发人员也必须使用它。需要就是否使用该工具做出决定。