1.康威定律
也称为：“您将承载组织结构。 ”
“任何设计系统的组织都将产生其结构是组织通信结构副本的设计。”
您可能认为可以通过跨职能的站立会议、利益相关者更新和决策矩阵来避免这种情况，但是最终且不可避免地，优先级的冲突或分歧将导致流程和结果同样冲突或分歧。
2.布鲁克斯定律
摘自《神话人月》：
“为一个较晚的软件项目增加人力会使其变得更晚。”
当您意识到自己没有达到预期的进展并且您的管理层尝试从组织的另一部分重新分配资源时，您不仅会拖延项目，而且可能会使工作变得更加脆弱。
3.扎温斯基定律
“每个程序都会尝试扩展，直到它包含一个Web服务器，扩展到以至于无法扩展，最后被那些可以扩展的程序替换。”
对于Web服务，它是“ ...直到需要一个用户帐户并收集所有用户的数据”；对于物理设备，它是“ ...直到它包含一个不安全的wifi接入点，并且您无法更改其默认密码。还有一个Web服务器”。
4.帕金森定律
“工作正在延长，以填补完成工作所需的时间。”
这里主要的项目管理教训是，如果您没有为至少是概念上的里程碑设置大致的截止日期，那么这个项目将永远无法完成。这就是为什么在固定的时间表内迭代最小可行产品很重要的原因。
5.帕累托的谬误
当您完成80％的工作时，您认为您只剩下20％。
这里被忽略的关键部分是那20％会占用您80％的时间
6.鲟鱼的启示
90％事情都是CRUD的。
7.彼得原理
在等级制度中，每位员工都趋于提高自己的无能水平。因此，随着时间的流逝，每一个职位往往都被不称职的员工占据。
8.伊格森定律
您六个月或更长时间没有看过的自己的代码变成了像是由其他人编写的。
9. Greenspun的第十条编程规则
任何定制开发的系统都包含临时的、非正式指定的、漏洞百出的、缓慢地实施了一半的的行业标准
10.冰山谬误
开发新软件产品的成本仅占老板预算的总成本的25％，75%用于维护成本。
11. LGTM困境
如果要快速交付10行代码的更改，请将其隐藏在1500行pull请求中(躲过代码审查)。