人月神话
这是可以被任何人运行、测试、修复和扩展的程序。它可以运行在多种操作系统平台上，供多套数据使用。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 96-97
首先是一种创建事物的纯粹快乐。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 111-111
程序员凭空地运用自己的想象，来建造自己的"城堡"。很少有这样的介质--创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 120-121
Notes: 1) 写作啊
进度监督 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 164-164
。Dorothy Sayers在她的"The Mind of the Maker"一书中，将创造性活动分为三个阶段：构思、实现和交流 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 170-171
对于创造者，只有在实现的过程中，才能发现我们构思的不完整性和不一致性 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 175-176
在许多创造性活动中，往往很难掌握活动实施的介质 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 177-177
而我们的构思是有缺陷的，因此总会有bug。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 184-184
人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流（图2.1）。这在割小麦或收获棉花的工作中是可行的； 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 192-193
必须在计划工作中考虑沟通的工作量。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 199-199
对于软件任务的进度安排，以下是我使用了很多年的经验法则： 1/3计划 1/6编码 1/4构件测试和早期系统测试 1/4系统测试，所有的构件已完成 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 215-218
，一个具有丰富经验的硬件工程师的忠告："避免小的偏差（Take no small slips）"。也就是说，在新的进度安排中分配充分的时间，以确保工作能仔细、彻底地完成，从而无需重新确定时间进度表。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 251-252
简单、武断地重复一下Brooks法则： 向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later） 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 275-276
。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异！ 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 290-291
这就是小型、精干队伍概念上的问题：对于真正意义上的大型系统，它太慢了 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 306-306
而语言专家则寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 356-356
我主张在系统设计中，概念完整性应该是最重要的考虑因素。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 402-403
由于目标是易用性，功能与理解上复杂程度的比值才是系统设计的最终测试标准 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 416-417
功能， 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 419-419
简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致的折衷机制。在 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 425-426
第一种是仔细地区分设计方法和具体实现。第二种是前一章节中所讨论的、一种崭新的组建编程开发团队的方法。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 430-431
对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 431-432
系统的体系结构（architecture）指的是完整和详细的用户接口说明。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 434-434
实际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 459-460
际上，产品的成本性能比很大程度上依靠实现人员，就如同易用性很大程度上依赖结构师一样。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 460-460
基于上述理由，再加上"未来产品"的质量手册将诞生于"今天产品" 的备忘录，所以正确的文档结构非常重要。事 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 740-741
减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 782-783
原因有两个：第一，同时具有管理技能和技术技能的人很难找到。思考者很少，实干家更少，思考者－实干家太少了。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 805-806
数据的表现形式是编程的根本 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 978-979
更普遍的是，战略上突破常来自数据或表的重新表达--这是程序的核心所在。如果提供了程序流程图，而没有表数据，我仍然会很迷惑。而给我看表数据，往往就不再需要流程图，程序结构是非常清晰的 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 981-983
做什么：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。 做什么：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。 时间：进度表 资金：预算 地点：工作空间分配 人员：组织图。它 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 1034-1037
因为项目经理的基本职责是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 1044-1045
。一个原因是只有一小部分管理人员的时间--可能只有20%--用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、讲授、规劝、讨论、鼓励。 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 1049-1050
一个接一个的软件项目都是一开始设计算法，然后将算法应用到待发布的软件中，接着根据时间进度把第一次开发的产品发布给顾客 弗雷德里克·布鲁克斯, 人月神话(二十周年纪念版), loc. 1066-1067