本周我阅读了《人月神话》
编程，一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动。焦油坑确实是一个新颖而又贴切的比喻，大型系统开发就犹如这样一个焦油坑，乐趣与痛苦交织，各种团队在其中挣扎，而这本书试图提供桥梁，为通过这样的焦油坑提供一些指导。
人月神话，初读书名实在是有些疑惑。实际上，人月是估计和进度安排中的一个单位，他暗示着人员数量和时间是可以相互转化的。然而这仅仅是个神话。书中分几点说明了这一点：
- 乐观主义导致的错误进度安排
一个普遍假设是：一切都将运作良好，每一项任务仅花 费它所“应该”花费的时间。我们可能不会意识到，但往往这正是大多数时候我们安排计划存在的假设。然而现实不会如此，意外的概率总是存在，墨菲定律也告诉我们这一点。
- 试图以增加人数赶上进度并不现实
软件开发本质上是一项系统工作，错综复杂关系下的一种实践，沟通、交流 的工作量非常大。时间不是工作量除以人数，一味地添加人数甚至可能导致延长工作安排。
- 充足的系统测试非常重要
不为系统测试安排足够的时间简直就是一场灾难，其导致的二次成本远高于其他花销。
- 空泛的估算
非阶段化方法的采用，少得可怜的数据支持，加上完全借助软件经理的 直觉，这样的方式很难生产出健壮可靠和规避风险的估计。
- 削减任务往往是唯一可行的方法
团队是软件开发的核心，不同组织形式的团队在效率上可能有天壤之别。外科手术队伍，通过专业化的角色分工，避免了一拥而上的情况，使简单的交流成为可能。而对于非常大型的项目，需要很多人协作，概念的完整性至关重要。这就需要少数架构师，专注考虑结构的完整性，所谓贵族政治。这不意味着实现人员不能具有创造性，但是不能与系统基本概念进行整合的良好想法和特色，最好放到一边， 不予考虑。
巴比伦塔，一个工程壮举，同时也是第一个彻底失败的工程。我们可以从这个故事中得到很多借鉴的地方。故事中的人们具有人力，材料，技术等条件，至少没有在失败前造成限制，他们缺少的是交流，以及交流的结果——组织。当交流无法进行，或者进入歧途，左手不知道右手在干什么，必然会导致工程的失败。团队中的交流途径主要包括：非正式途径（日常）；会议；工作手册。我们往往认为较小的项目不需要手册或者规范，但往往会导致一系列的问题。口头的规范和守则，往往缺乏约束力，实施起来也有颇多困难，一个精简有效的工作手册是有必要的。
软件工程方面有很多不同的技术，管理方法，但并没有像银弹那样对狼人有效的一劳永逸的方法。这其中的根本困难是规格化、设计和测试概念上的结构。现代软件系统中无法规避的内在特性：复杂度、一致性、可变性和不可见性，同样告诉我们这一点。