第1章
经典语句：
布鲁克斯法则：往以延误的项目中补填人手，只会使其继续延误。
在实际开发中，编码只占软件项目开发时间的1/6，有一半时间用于测试和修正缺陷。
好的程序员懂得写什么，卓越的程序员懂得改写（并复用）什么。若能取之于现有，陈寻缘决不肯创之于无本。
与其害怕竞争对手窃取代码而秘不示人，不如将其展现给全世界，邀请同道加入。
李纳斯法则：只要有足够多的beta版测试人员和开发者队伍，几乎所有问题都会很快被发现，而且总有人知道该怎么修复。‘眼球足够多，缺陷无处躲’。
“乐享即能高效，愉悦是金”。
棒球队经理视进取精神为伟大球员和伟大球队的天赋要素。奔跑快过所需，以为想过所需，努力大过所需。对于伟大的编程团队，这也是必备要素。
本章以一个开源基金会的项目小组的研发会议开题，讲述了该项目小组在软件开发过程中遇到的最常见的问题，项目进度延期。引入了布鲁克斯的人月神话，讲述了布鲁克斯关于团队开发过程中的经验看法。接着讲述了开源项目的由来与发展。然后说明了开源项目中和布鲁克斯理论的相悖之处。
系统架构师在总结项目进度落后的原因时说道，“我们一直没有蓝图，所以会碰上没有预料的问题。”前不久我也在老师的的逼迫下不得已需要做一个项目，确切的讲我并不认为那算是一个严格的项目。我组建的开发小组只是为了完成任务而已，我们的项目没有设计文档，没有明确的分工合作，开发之前只是确定了题目后简单模糊的划分了模块，开发过程中也是各自干各自的，几乎没有过问过彼此之间的任务。最后到了展示结果之前，我们将各自的东西拿到一起来的时候发现最大的问题就是几个模块不能组合到一起。在开发之初，我是希望我们可以做好软件设计的，我曾幻想着我是如何将软件整体划分为多个模块之后，在各个模块之间定义好接口的，最后又是如何组装各个模块的。但是当我在团队的研发会议上的时候，我发现我根本不知道该如何阐述我的想法，活着我根本就没有想法吧。也许我并不适合领导一个小组吧。
我也想过究竟是我掌握的技术水平过关还是缺乏开发经验。现在回想起那段开发过程，我似乎将大部分时间都花费在了学习技术和编写代码上了。但是当我写完一段代码后发现这段代码并不适合使用，于是又推到重写，这样反反复复之下重复的工作做了好几遍，最后也没有得到想要的结果。如果我从来一开始就知道改写什么样的代码该多好啊。