软件复杂度的来源：业务逻辑、用户规模、性能要求。
软件是为了承载业务而创建的。复杂的业务逻辑必然导致复杂的软件。但是除了业务逻辑之外，用户规模和性能要求，也会导致软件复杂度的增加。如果不考虑执行效率，单纯从逻辑上看，软件能够做的事情，人也可以完成。我们可以把人在执行业务流程时的状态作为参考。比如一个客户到银行申请开立账户，服务人员是如何执行业务流程的呢？他首先会查看客户的身份证件，确认客户的身份。接着检查客户是否在黑名单上。然后检查客户提交的资料是否完整、有效。如果一切检查通过，服务人员为客户开立账户，并将客户资料归档。在整个过程中，核心步骤“开立账户”只是其中的一部分，更多的步骤是在执行检查、归档等非核心操作步骤。因此我们可以将业务流程分为两个部分：核心步骤和辅助步骤。软件也可以按照类似的方法，分为核心（业务逻辑）模块，和辅助支持模块（如存储）。核心模块执行业务流程，辅助模块为业务流程的执行提供保障。所以软件整体的复杂度，由核心模块复杂度和辅助模块的复杂度共同决定。对于复杂的业务逻辑，核心模块的复杂度高。对于大用户规模和高性能要求，为了保证性能指标符合要求，辅助模块需要尽最大可能使用计算机资源，这需要大量的技术和技巧，导致辅助模块的复杂度增加。
软件复杂度=业务逻辑复杂度x用户规模x性能要求
采用建筑来比喻。业务逻辑复杂的软件，就像一个P4生物实验室：楼层不高、面积不大，但是内部结构和设施复杂。用户规模大的软件，则像是一个包含一万座小楼的建筑群。单独看每个小楼的建造很简单，但是由于规模大，构造过程中的资金、物资、人员调配非常复杂。同时如果设计存在缺陷，将会导致巨大的资源浪费和时间超期。性能要求高的软件，像是一座1000层的高塔，要考虑诸如地基塌陷、高空防风等各种普通建筑不需要面对的问题。如果哪个问题考虑不周，整个高塔将无法建成。
一千个读者眼中有一千个哈姆雷特。每个人、每个团队对业务规则、用户规模和性能要求的理解和认知各不相同。要采用哪一种理解和认知呢？应当也必然采用符合康威（Conway）定律的那一种。所以软件复杂度的真正来源是：符合Conway定律的，假想的业务逻辑、用户规模、性能要求。