这是来自一篇生产实践的经验分享，程序员对技术热情，而不是对业务理解的热情会误导企业软件方向，导致很多挫折和失败，技术不是越新越先进越好，而应该匹配业务领域：
“优秀的程序员对他们的工作充满热情”基本上是我们行业的常见现象。总的来说，这可能是真的，但最近我一直对“编程的热情如何妨碍我们为公司工作得更好”而感到兴趣，甚至可能导致我们在编程时更糟糕。
以下是我认为这种激情会让我们的工作变得更糟的一些方法：
（1）忽略了业务领域在构建优雅解决方案中的重要性。
（2）关于技术债务风险的判断不佳（因为启发式影响）
（3）坚持孤立主义，这可以使企业构建错误的东西。
（4）生成器与市场质量不匹配，这会导致浪费精力。
（5）过度专业化
这些都是我个人犯过的错误，虽然我认为编程的热情和这些错误之间没有必要的联系，但我认为我的激情在解释我这个特殊情况下发生的一些错误中起到了因果作用。我认为这是违反直觉的，值得分享以防其他人发现自己处于类似情况。
让我们详细看看每个错误。
忽视领域
Eric Evans 以极好的观察力打开领域驱动设计：
软件的核心是它能够为其用户解决与领域相关的问题......开发人员必须让自己进入业务领域中以建立业务知识......然而，这些并不是现实中大多数软件项目的优先考虑事项......
大多数才华横溢的开发人员对了解他们工作的具体业务领域并不感兴趣，更不用说承诺扩展他们的领域建模技能了。技术人员更愿意也更享受锻炼其有关技术技能(而非业务)的可量化问题。
如果Evans有关领域建模对于优秀软件的重要性的观点是正确的，那么我们实际上更关注技术问题的倾向会让我们分散我们建立优秀软件所需的设计对话。
他在同一篇文章中对此有一个很好的比喻。领域无知的开发者就像一个摄影爱好者选择了一个更好的镜头，因为总会有人走进那个镜头。
他说：电影制作人员专注于精确执行自己的专业。他担心看过这部电影的其他电影编辑会根据其技术完美程度判断他的作品。在这个过程中，场景的核心已经丢失。
影响技术债务风险的启发式模糊判断
我们作为程序员所做的很大一部分是管理技术债务。不幸的是，我们管理这种技术债务的大部分方式取决于我们对代码库中技术债务的风险和影响的直观判断。这些直观的判断将贯穿于影响启发式，这是我们潜意识用来通过考虑我们对X的情绪反应来判断X风险的心理捷径。
作为程序员，我们不喜欢代码废话，因此我们可能会高估代码对业务造成的风险。受到广泛尊重的程序员认为：通常还有其他更重要的因素会对企业造成风险。这是两个例子：
良好的工程设计可能是项目成功的20％。糟糕的工程肯定会伤害项目，但只要其他80％的产品线正确，适度的工程设计就可以使项目取得成功......
KentBeck，TDD示例
对于我们研究的绝大多数失败项目，没有一个技术问题可以用来作为解释失败的原因。我们的调查参与者最常引用的失败原因是“政治”。
程序员隔离主义
考虑两个关于程序员如何参与非编程活动的观点：
在Joel Spolsky的观点中，开发人员应该通过“开发人员抽象层”与业务隔离。事实上，他说，“管理层的主要责任是创建l幻觉：软件公司可以通过编写代码来运行，因为编写代码是程序员所做的工作“。
Marty Cagan有一个非常不同的看法。他说，“如果你的程序员只是编程，你只能获得一半的价值。”支持驱动的开发还需要软件开发人员实际上提供客户支持 ，甚至成为像Zapier 1和Wufoo 2这样的公司。
简单地追问哪个观点更正确本身是一个糟糕的问题。更好的追问是：
在哪种情况下每种观点更合适？
我们通常会针对正确的情况选择正确的观点吗？
我认为我们经常搞砸了，我认为程序员的激情与这个错误有关。我认为我们往往倾向于支持Spolskian观点（第一个观点）。但是当一个项目的“如何做”比“做什么”更模糊，我们才应该更倾向于Spolskian的观点；当“做什么”比“如何做”更为模糊时更倾向于Caganesque的观点。
如果您确切地知道您需要构建什么，但是您关心的是如何构建它，那么将开发人员与业务隔离开来就是一个很好的选择。
如果你不知道你需要构建什么以及如何做是相当简单的，那么应该招募开发人员来帮助企业了解要构建的内容。这意味着程序员可以提供构建内容的可能性空间的精彩地图。
问题在于，我们对技术问题的热爱可以使企业为错误的环境选择错误的观点。
如果企业想要隔离我们，以便我们可以愉快编程，真棒。你不会得到我们的任何争论。我们将忙于编程。
由于作为程序员自身成长通常是依赖一大群用户实际使用产品之后才会发生，允许业务这些错误发生对于我们作为程序员的成长和对业务造成的不利影响实际上是不利的。
（banq注：很多企业将业务开发和技术开发进行分离，业务开发只负责业务数据库之类开发，而技术开发则是提供业务以外的其他技术组件 框架中间件和平台开发，这种业务孤立主义需要视具体企业所在环境上下游而定。）
开发产品高于市场质量标准
让我们从坦白开始：我经常让自己“修复fix”我不愿再多看一眼的某部分代码库。即使这不会导致意外的错误，通常也需要一段时间才能交付。“只是解决技术债务，”我说。
有些人却能坦然处之，我曾在雅虎见过一位工程师说在开发冲刺计划期间可以调用“开发者幸福”来证明在某些事情上的合理性。Peopleware的作者实际上声称软件质量应该由程序员而不是市场来设定。他们说：
“我们都倾向于将自尊与我们生产的产品的质量紧密联系在一起...... 只要你忽视对开发商的态度和效果的影响，市场衍生的质量标准似乎才有意义......”
这是一个强烈的主张，我怀疑是完全正确的，但在某种程度上，这是真的，这意味着公司浪费资金满足我们的质量欲望，因为我们的质量标准超出了市场对质量的要求。
这在启动时尤其成问题。早期创业是一场生存的战争，所以当我们对编程的热情驱使我们坚持比我们客户的要求更高的质量时，我们最终表现得就像那些被困在战壕中的士兵一样抛光我们的步枪因为它让我们感觉更好。(banq注：对技术热情会提供高质量的产品，但是市场不需要这么高质量，而高质量需要成本和时间，创业企业会错失良机，敏捷更重要，使用Ruby/PHP开发一个网站可能会比用Java更有效，虽然没有细粒度的分层架构)
我并不是说关心软件质量不是好事情，我只是认为在创业公司，如果程序员专注于这些事情而不是生存，那就太难生存了。
过度专业化
有一段时间了，我怀疑程序员的专业化对于企业来说反而应该是次优的。Andy Grove的用餐比喻和他在High Output Management中的“限制步骤”的概念给了我一个很好的方式来解释为什么这可能是真的。
Grove说：如果我们想要熟练地运营一家餐馆（或招募人才，或者建立一个编译器），我们最好确定创建早餐所需过程中的“限制步骤”：在含有鸡蛋，烤面包和咖啡的早餐中，准备鸡蛋是限制步骤。
这是因为准备鸡蛋需要花费所有步骤的大部分时间。无论我们准备咖啡和烤面包的速度有多快，我们所供应的早餐数量最终将受到鸡蛋准备时间的限制，这反过来限制了用餐者可以产生的收入。在许多技术公司中，有一种类似于鸡蛋制备的技能，因为它限制了可以开发功能的总体速率，这反过来限制了公司可以从这些功能中产生的收入。
上述餐厅的一名员工认为提高她的咖啡准备技能实际上会帮助企业弄错。这同样适用于那些认为专注于非限制性规则对业务有利的程序员。程序员对他“最喜欢的技术堆栈”的热情可以使她失明。
在很多情况下，即使程序员专注于非限制性规则/堆栈，持续专业化实际上也会为业务带来好处。专家可能能够在更短的时间内生成更高质量的代码，从而减少错误，这可能会导致软件产品的推荐人数增加。此外，更深入的知识可以更加丰富地了解指定技术堆栈的可能性，从而更好地为产品和项目管理决策提供信息。
然而，在某些时候，对质量的进一步投资和跟上解决问题的所有最新方法将会产生收益递减，我怀疑这一点比我们很多人意识到的要早得多。
总结：这是来自一篇生产实践的经验分享，程序员对技术热情，而不是对业务理解的热情会误导企业软件方向，导致很多挫折和失败，技术不是越新越先进越好，而应该匹配业务领域，领域驱动设计=业务领域驱动设计=业务驱动设计，而我们平时是技术驱动设计或者数据驱动设计，后两者都过于偏重技术！