软件设计与康威定理是两种不同的东西，软件设计是针对软件的，康威定律认为团队组织管理方式决定了软件的设计，因为这两者本身就属于一个大系统。
但是虽然你的团队划分按照康威定律，最终软件设计还是不行，原因是康威定律并不适用于刚性的硬设计，Mathias Verraes这篇新文章认为：
人事方面的人员重组可能会帮助你获得你想要的系统设计，但是前提是这个系统必须是全新的重新开始的新系统，或者这个系统至少在适应组织方面非常灵活。如果是设计已经僵化了的旧系统，重构没有用，换人的人事重组也不会。
文章还批评了规则引擎本身的局限，它还是一种分割思维的体现，没有从整个系统高度去设计，这篇文章也强调了复杂性系统的思维和通常科学分析思维的区别。以下文章摘要，详细点击标题：
逆康威定律 是一种组织工程方式：它告诉我们需要改变团队和组织结构才能实现我们想要的系统设计。越来越多的组织根据这个想法进行重组，但他们最终却没有得到他们想要的系统。
我们什么地方弄错了？
例如，GitHub是一家分布式公司，利用GitHub建立了一个分布式协作的工具。虽然系统确实模仿了他们的组织结构，但改变组织似乎并没有产生同样的效果。
这是因为我们没有考虑到设计中的系统本身的属性。
理论本身就是系统
康威Conway博士描述了一种 "系统的线性图与设计组织的线性图之间的结构保持关系 "。他对 "系统 "的定义比 "软件系统 "要宽泛得多。因此他的康威定理定义更符合系统理论，即（松散的定义）所有的东西都是一个系统，所有的东西都是一个系统的一部分。
例如，康威写道："在同样的意义上，一个理论是一个系统，这可能不那么明显"。他的例子涉及调查员形成了一个关于飞机如何坠毁的理论：调查员们根据他们的专业领域，对导致坠机的不同事件创建了子理论。该理论的结构将模仿调查员组织的通信结构。
一个软件系统并不是生活在真空中。它被嵌入到生产这个系统的组织中。它受我们关于软件的理论支配：它是如何工作的，它做什么，它为什么这样做，它是如何连接的。我们把这些理论称为 "模型 "和 "架构"。
在一些组织中，这些理论只存在于人们的头脑中。其他人则用图表和文件来表达这些。如果他们持续关注这些模型的协作和发展，那就更好了（例如，使用领域驱动设计）。但是，无论你是否有图表，每个使用或设计系统的人都有一些关于该系统的理论。如果不对这些理论进行明确的建模，我们不仅有可能得到一个糟糕的系统设计，还有可能得到关于这个系统的错误信念。
规则引擎等反面案例
十多年前，我曾为一家SaaS公司提供咨询。我发现，在CEO、销售人员、客户成功经理和培训师、客户和工程师之间，对系统如何运作的信念差异很大。如果你立即认为工程师有最好的理论：不。他们对设计（主要是由他们的前辈创造的）了解甚少，以至于他们每晚都要删除和重建客户仪表板数据库。这是他们能在结果中获得一些一致性的唯一方法。
另一个例子是Aardling的一个客户，一个在具有复杂监管要求的领域运营的B2B公司。在创建公司时，首席执行官（一个领域专家）和首席技术官同意首席技术官不参与这个领域的复杂性。相反，技术将以一种允许技术保持与该领域无关的方式来构建。为了做到这一点，工程师们建立了一个表单生成器、一个规则引擎和一个模板语言。他们聘请了（非技术性的）领域专家，并教他们如何使用这些工具来建立面向客户的功能。
快进到几年后。从系统设计到产品再到组织控制结构，关于公司应该如何运作的理论已经渗透到了所有的东西中。
但你只能用表单和规则引擎做这么多。
用这些工具可以很容易地建立起一些功能，有快速的周转时间，但其他一切都必须由工程师来完成。这需要预算和优先级，而且往往是通过捷径完成的，这反过来又使后续的修改更加困难。整个设置使其无法实现某些增长目标。这些团队没有自主权，需要大量的协调来实现任何目标？重组能解决这个问题吗？尽管系统设计模仿了公司成立初期的沟通结构，但现在的系统太僵化了，仅仅是团队的洗牌是无法影响的。
僵化的系统
逆康威定理的倡导者告诉我们，我们所要做的就是重组团队以获得更好的系统设计。但是，如果软件本身，创造它的人类（社会技术）环境，以及人们对系统的信念，都只是属于他们自己的另外一套系统，而且他们都受到组织的沟通结构的影响，那么应用这个定理就变得更加混乱。
为了有效地干预我上面的两个例子，你必须解决组织、系统以及人们对组织和系统的理论。
软件应该是柔软的，也就是说，可塑性强，容易改变。
通常情况下，它其实不是容易改变的，因为这些系统通常是深度耦合和相互连接的。
改变一个组件会产生连锁反应，不仅仅是在软件组件中，而是在整个组织和客户的生态系统中。如果我们的软件的这种僵化性是我们的主要瓶颈之一，你会认为我们会急于解决这个问题。然而，令人失望的是，很少有软件组织对其软件的深层结构改进给予足够的重视。
相反，他们转向了重组。而这是一个诱人的承诺：改变你的组织，得到你想要的系统设计。它甚至带有法律，所以它不会失败! 然而，正如一位客户的首席技术官曾经告诉我的，"我们重组了，但是系统没有收到备忘录"。(有一个挽回的因素：管理者只能间接地影响软件系统，而他们唯一的工具是会议和重组)。
（banq：从代码重构 到代码重写，再到换人：组织重组，经过这三个阶段血流成河，损失巨大，人才流失严重，最后还是失败，关键是没有人知道软件工程失败的深层逻辑与原因）
扩展康威法则以说明刚性问题
康威法则是错的吗？不，我不这么认为。当从头开始设计一个系统时，它是正确的，这正是本文所描述的。当使用一个灵活的系统设计时，它是正确的，因为它足够灵活，可以适应模仿新的团队之间交流沟通结构。
但它不能很好地转移到适用现有的具有刚性设计的系统中。
我建议这样做：
系统设计将模仿组织的沟通结构，但只是在设计的灵活性允许的范围内。
Conway博士评论说："我认为[沟通结构和系统设计之间]的关系是一种约束，仅此而已。你可以通过扰乱一方或另一方来改变什么，取决于它们的具体特征 "。
因此，"反康威演习 "也需要被扩展。
如果系统是新的或灵活的，改变组织结构以获得你想要的系统设计；如果系统是僵化的，就先解决这个问题。
或者，更简明的说法是：
人员重组并不能解决一个破碎的设计。
当涉及到新系统的设计时，康威定律被低估了，但当涉及到现有系统的重新设计时，却被夸大了。
一个新的绿地项目有无限的灵活性。但随着设计中更多的耦合和互连，它就失去了灵活性。我们需要尽早地、持续地考虑我们的组织结构，而不是在设计僵化后才去考虑。
防止我们的系统变得僵化需要持续的关注，从成千上万的小的局部设计决定到大规模的架构。为了支持和促成决策，我们需要关于系统、领域、产品和它所服务的生态系统的良好模型或理论。
当我们发现自己面对的是一个僵硬的系统时，反康威演习只是我们可以使用的工程设备之一，而不是一个魔杖。
归根结底，好的设计是导致良好设计的系统的原因。