与其他领域一样，软件开发领域也有一些非常经典的定律。这些定律包括了一些法则或软件开发大神的名言。
也就是所谓的“按照组织架构来交付软件”：
“任何一个组织在设计一个系统时，这个系统的结构与这个组织的沟通结构是一致的”。
你或许认为可以通过一些方式来避免这个定律，比如跨功能团队的站会、进度更新和决策矩阵，但最终都不可避免地会发生冲突和分歧，而这些将导致冲突和分歧的过程和结果。
这个定律来自《人月神话》：
“在一个已经延期的项目中增加人手只会让项目延期更长”。
当你意识到项目没有取得预期的进展，并尝试从其他地方调取更多的资源，不仅会让项目延期，而且更有可能交付一个更脆弱、更复杂的产品。
“每一个程序都会膨胀到需要加入 Web 服务器，不膨胀的程序最终会被膨胀的程序所代替”。
对 Web 服务来说，就是“膨胀到需要用户账号登录并收集所有用户的数据”。对物理服务来说，就是“膨胀到需要加入一个不安全的 WiFi 访问点，设置了你无法修改的默认密码，以及一个 Web 服务器”。
“一项工作会占用掉所有用来完成它的时间”。
如果你不给一个项目的里程碑阶段设置截止日期，这个项目就永远完成不了。这就是为什么一定要给一个 MVP（最小可行产品）定一个固定的截止日期。
当然，这个定律也可以用在数据、算力、内存等方面：
“程序最终会把所有可用的存储空间、CPU 时间和内存用光”。
帕累托原则很容易被曲解，尤其是被管理层曲解，这通常会导致帕累托谬论的出现：
“当你完成了 80%的工作，你会认为真的只剩下 20%的工作要做”。
但你可能低估了剩下的 20%工作，因为它可能占用你 80%的时间。
“90%的东西都是垃圾”。
是的，包括你的产品在内。
“在一个等级制度中，每个员工都倾向于升到他们学历无法胜任的职位。因此，随着时间的推移，每个岗位都有可能被不称职的员工占据”。
“你写的任何超过 6 个月没有看过的代码，有可能已经被别人改过了”。
这里说的 6 个月已经是一个很乐观的数字了。
不过，有一点需要注意，那就是“Yo Momma 推论”：只有作者才可以给代码提出批评，任何其他的负面反馈都将被驳回。
用在认证方面：
任何一个定制开发的认证系统都包含一个临时的、非正式的、隐藏缺陷的、运行缓慢的 Kerberos 不完整实现。
这可以概括成一般性的 NIH 规则：“任何一个定制开发的系统都包含一个临时的、非正式、隐藏缺陷的、运行缓慢的行业标准的不完整实现（因为你拒绝直接使用标准实现）”。
“一款新软件的开发成本只占管理层预算的总成本的 25%左右”。
运维界的一句格言：
如果说软件维护的成本占了总预算的 75%，那么这 75%都应该是运维支持。
“如果你想快速提交 10 行代码变更，可以把它隐藏在一个 1500 行的 PR 中”。
