人月神话

人月

人月（英语：man-month）指的是“一个人要花几个月”才能完成软件开发的单位，通常用来评估一件软件项目的大小。以成本会计（cost accounting）为基础的时程预估技术，使我们误把工作量和项目进度混为一谈，人月是个危险并很容易就遭到误解的迷思（myth），因为它假设人力和工时可以互换。

Brooks法则

在一个时程已经落后的软件项目中增加人手，只会让它更加落后。根据Brooks法则，增加人员到一个已经延误的项目里，等于是火上加油。除非你可以把工作区分，让新进人员可在不影响他人工作的状况下有所贡献。
把工作切分给更多人做将造成额外的沟通（communication）代价——训练和相互的交流（intercommunication）。欲增加软件项目的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。

外科手术团队

在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当领导者，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。
以一位首席程序员为主、类似于外科手术团队的组织提供了一个良方，既可因少数人的决策而兼顾到产品的整体性，又可因多数人的合作与大幅沟通减少而得到全部人的生产力。

第二系统效应

第二系统效应（英语：The second-system effect）就一个人所做过的设计而言，第二个系统是最危险的系统，一般来说，都倾向于过度设计。
当他做第三或之后的系统时，之前的经验会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部分。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟当前项目的基本系统假设有冲突而不再适用，OS/360有好多这样的例子。（Windows NT则似乎是1990年代的示例）
对大部分OS/360的设计人员来说，它也是个第二系统，设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury即时系统、给7090用的IBSYS操作系统等等，几乎没有人拥有两个上述系统的发展经验，所以OS/360可称得上是一个最佳的第二系统效应示例。

项目工作手册

手册或书面规格是不可或缺的工具，虽然光靠它是不够的。手册载明的是产品的外部（external）规格，用来描述并制定出用户从外观上将或看到的所有细节，撰写手册便是架构设计师的主要工作。当用户和实现人员的反应不断地显示出设计上难以使用或实现之处，手册就会堕入重新准备、修改的轮回之中。为了造福实现人员，将修改的程度予以量化（quantize）是很重要的——在时程上应该要有载明日期的版本信息。

软件需求

失败的软件项目经常发生在开发者与用户间对需求认知的误解。开发者抱怨用户说不清楚需求，而用户抱怨开发者误解他们的意思。布鲁克斯认为“软件开发最困难的单一项目，是精确地决定要建造什么。”