初读《人月神话》(the mythical man and month), 看到一些剔醍醐灌顶的句子, 抄录如下, 希望能在实践中消化吸收, 化为内功心法.
将定义书写成文字，必须对很多原先并不是非常重要的问题进行判断，并得出结论。
定义规定什么的同时，也要定义未规定什么
手册不但要描述包括所有界面在内的用户可见的一切, 它同时还要避免描述用户看不见的事物.
精确和完整的定义所有的接口后, 研发人员只需要了解自己负责的部分, 而无需去了解整个系统.
数据的表现形式是编程的根本
书面记录决策是必要的. 只有记录下来, 分歧才会明朗, 矛盾才会突出.书写这项活动, 需要上百次的细小决定, 正式由于它们的存在, 人们才能从令人迷惑的现象中得到清晰, 确定的策略.
事物在最初总是最好的
系统软件开发是减少混乱度(减少熵)的过程, 所以它本身是处于亚稳态的. 软件维护是提高混乱度(增加熵)的过程,即使是最熟练的软件维护工作, 也只是放缓了系统退化到非稳态的进程.
软件的模块总数量随版本号的增加呈线性增长,但是受到影响的模块以版本号指数的级别增长. 所有修改都倾向于破坏系统的架构, 增加了系统的混乱成都(熵增). 用在修复原有设计上的瑕疵的工作量越来越少, 而早期维护活动本身所引起的漏洞的修复工作越来越多. 随着时间的推移, 系统会变得越来越无序,修复工作迟早会失去根基.
软件的复杂度是根本属性，不是次要因素。因此，抽掉复杂度的软件实体描述常常也去掉了一些本质属性。数学和物理学在过去三个世纪取得了巨大的进步，数学家和物理学家们为复杂的现象建立了简化的模型，从模型中抽取出各种特性，并通过试验来验证这些特性。这些方法之所以可行，是因为模型中忽略的复杂度不是被研究现象的根本属性。当复杂度是本质特性时，这些方法就行不通了。
首先, 项目的关键问题是沟通, 个性化的工具妨碍而不是促进沟通.其次, 当机器和工作语言发生变化时,技术也会随之变化.所有工具的生命周期都是很短的.
自动编程 和 图形化编程, (到目前也没有突破, 最近印度那家的融资骗局)
软件开发人员为客户所承担的最重要的职能就是不断重复地抽取和细化产品的需求.
复杂性是最严重的内在困难, 但并不是所有的复杂性都是不可避免的. 我们的很多软件, 但不是全部, 来自应用本身随意的复杂特性.
昨天的复杂性是今天的规律. 我相信有一天软件的复杂性将以某种更高级的规律性概念来解释.
程序员不愿意为设计书写文档, 不仅仅是因为惰性, 更多的是源于设计人员的踌躇--要为自己常识性的设计决策进行辩解.
根据接口最小化和边界严格清晰化, 将系统分解成子系统.
概念完整性是产品质量的核心.
对于任何软件产品, 任何用户群属性实际上都是一种概率分布, 每个属性具有若干可能的值, 每个值有自己发生的频率.为了得到完整, 明确和共享的用户描述, 机构是应该猜测(guess), 或者假设(postulate)一系列完整的属性和频率值. 进而根据假设, 去做 AB test...
对于软件工程领域 主要的问题实质上更侧重于社会学(sociological)而不是科学技术(technological).
