由中央高智能部门协调和控制软件的大批量发布经常会失败，其原因是由于数学NP问题以及人类之间的弱相互影响。
大多数公司以某种命令和控制方法开始软件版本发布，这是一种中央智能组织推动和控制工作流程，批量大小为N的发布策略是问题所在。
首先是数学上行不通，像很多问题一样，我们可以使用N（在我们的案例中为故事总数，依赖项数量，受影响的模块数量，“合并冲突”的数量之和）作为这个问题的输入数量的粗略指标。随着N的增加，大多数问题都变得更难解决。
我们可以使用采用N的某种表达式来表达他们要付出多少努力。如果该表达式是多项式，则称为P问题。如果不是，则称为NP问题。
这个问题就变成了计算机中复杂性的问题：NP Complete问题（NP完全问题），就是说即使N的增加很少，也会使难度增加到惊人的大。
直觉是，可靠地交付批次大小为N的发行版的问题是NP complete（完全问题），这是一种软件的包装，是确切的。
人与机器始终以小N来解决NP完全问题的特定情况。关键：并不是每次实例都是不可解决的。确切地说，N的微小增加会迅速导致此类问题“在宇宙热死之前无法可靠地解决”。
“可靠地”这个词很重要。您会看到，在解决NP完全问题时，可以通过生成候选解决方案并进行尝试来实现。如果问题有解决方案，那么您可能会在第一次尝试时就找到它。
这使我想到了第二个令人着迷的方面：团队可以花很长时间*经历*这个问题的NP完全问题，而没有意识到它。在这场比赛中，我们成功了一段时间，也许十分之一。但是我们失败了十分之九。但是我们更容易记住成功：“我们*几乎*做到了！”
几个小小的发行问题并不难解决，但是我们花了几个小时疯狂地奔波，急于捆绑新发现的遗漏的API端点，重建我们的应用程序，然后重新部署它。或者，在糟糕的日子里，我们沮丧地流着泪回去。
我们每个回合都会遇到一个或两个问题？他们每次都是不同的小问题：例如忘记了此链接、没有打开功能标志、不知道该功能依赖于我们删除的字段，每次碰到的问题都是小的狗屎，但是不同的狗屎。
我们没有在问题中看到模式，因为它不是模式，而是元模式：由于组合函数抛出了太多细节供我们考虑，因此出现了问题。我们的N开始启动使我们的问题无法可靠地解决。
第三个令人着迷的方面：软件发布还经常运转顺利。这些偶然的胜利彻底使水变得浑浊，因为它们确实只是组合运气。但是他们使我们相信，*每次*都有可能幸运。
可以肯定的是，人们可以采取措施改善自己的运气。在游戏中，这称为作弊。在计算机科学中，这确实是非常聪明。但是你不能消除运气。它内置于我们解决NP完整问题的性质中。
内卷化
因此，当我们失败时，我们会做两件事：
- 1）指责我们缺乏努力和意志，
- 2）增加更多规则，门槛和检查。
“我们只是没有尽力而为。” “我们需要将其添加到我们要检查的事物列表中。”我们提高了发布活动的严肃性，确保每个人都知道真正尝试，花时间，认真思考，避免犯下愚蠢错误的重要性。我们变得，我在这里不是在开玩笑，非常*忧郁*，皱着眉头，若有所思地点头。
我们只有少数几个人，我们要求他们协调所有这些工作，并每次都坚持工作，直到发布完成为止。我们奖励他们，但我们也要求他们在高压力下长时间工作，要求他们英勇。我们升级了流程。有新的签收。有清单。通过通用的自动化代码质量系统有强制性通行证。有一个正式的滚动时间表，每个人都签署了每个任务。
奇怪的是，尽管这些调整旨在帮助我们控制N个批次，但它们往往具有使N变大的实际效果，因为现在它会将这些额外的过程元素合并到问题中。
提高严肃性和赌注以后，也加剧了紧张局势。我们越来越发展到以责备为中心（内卷化）。我们更加了解所谓的“长杆”政治，没有人愿意成为帐篷中的长杆。我们生气了。
所有这一切都在发生，因为我们的N已经增长到足以破坏我们的算法的程度。我们已经达到了一个问题的新的复杂层面，该问题太大了以至于无法解决。
我们已经隐式或显式地假设：1批10个的大小与10批每批大小1个是完全相同，甚至更少，但是NP完整性说那是不对的。批量大小为10的组合杀手会杀死我们。
发布关键技术
发布关键技术包括：
- 1）pull & swarm：程序员拉取一个版本的源码，以该源码为中心，作为一个整体进行“交付”。我们使用整体编程，或成对，甚至只是坐在一起。一次一个故事，一路走过去。
- 2）测试驱动的开发：在编写代码之前进行测试比在编写代码之后进行测试更快，更便宜。但事实是，它只有在测试代码编写完成后才更“有效”。这是我们自以为是的基本一线安全网。
- 3）基于主干的开发：我们不使用复杂的源分支策略来驱动N。相反，我们从主干拉取代码，推向主干，从主干测试，从主干交付。
- 4）注重路径的故事和代码设计：我们对故事和代码的设计不仅要着眼于最终的工作，还必须着重于它们可以被发布，而又仍然小到可以容纳它们的路径，这将涉及根本的风格变化。
- 5）稳定且值得信赖的自动化：希望该过程的每个环节都能实现自动化。自动化需要坚如磐石，甚至比应用程序本身更坚固。必须对其进行维护并将其扩展到我们的最高水平。
这五种技术中的每一种都需要学习和实践，并且不能通过一道命令圣旨来立即开启其中的任何一种。我和其他人中的一些人已经撰写了广泛的文章，并提出了各种方法来迈出小步。
总结
随着N的增长，问题变得更加困难，以至于我们的所有进展都将停滞不前。这不是意志的失败，也不是规则的不足，而是简单的组合数学问题。
中央智能部门可以将某个NP完整问题的大批量发布发布到某个N，但不能超出此范围。否则它将会失败，更加频繁失败。对于成长中的组织而言，看到这一点并采取相应的措施是一项严峻的挑战。