作者讲了这样一个故事：一群很有经验的代码牛人在先进软件开发模式的指导下，没有资金压力，在更多大牛的带领下，原计划用一到两年的时间开发出一个备受期待的个人信息管理软件(PIM)，后来花了七年时间才完成这一创举，但是已经无人喝彩。而在故事中引发的各种案例以及带给读者的各种思考是本书的精华，略微全局总结了一下，感觉比仅仅是写代码与计算机或软件交流方面的，更多的感觉是做事行为方面的。
第1章 死定了
Bugzilla软件在我们的团队里没有使用过，我们主要用JIRA，主要是在软件快发布前用上一段时间，随着时间的推移，一些项目就慢慢不用了。
布鲁克斯法则：向已延误的项目中补充人力，只会使其继续延误。
做软件的人都听说过这个法则，但在项目吃紧的时候确实都忽略它的存在，或者认为这法则对自己的项目不成立。此时领导的决策通常不是靠大脑，而是凭通常的直觉，人多力量大，但在软件行业不适用。“十月怀胎，无论多少妇女参加都一样”，是个非常形象的比喻。
第2章 Agenda之魂
卡普尔（Mitchell Kapor）在接受戴维·甘斯的采访时说过的一段话：
在变成数字资本家之前，我曾教人超觉静坐，还在一家社区医院的精神科做过心理咨询师，这些经历对我影响极深。我拥有心理咨询的硕士学位。所以，我另有志趣。我只是误入计算机领域，无意成为比尔·盖茨----只有比尔·盖茨才能做比尔·盖茨。我向来不求做大公司、赚大钱。我只是办了家叫做莲花的小公司，做了个几百万人争相购买的软件产品，结果这家小公司陡然暴长，员工数千，每年收入数亿美元。很不爽。至少对我个人来说，很不爽。所以我离开了。在某一天，我离开了。
第3章 原型与Python
语言的选择可能都是一个项目在前期选择时必须要经历的痛苦抉择。
文中谈到了汇编、Fortran、C、Perl，谈到了编译型语言和解释型语言，最后项目用Python语言来实现。
这章里提到了RDF（Resource Description Framework），好像在今年结题的国家863项目中也听到过这个名词，原来这玩意可以用来描述万维网中的语义。
电梯游说：就是当你有幸在电梯间遇到某位权钱人士时，能脱口而出，在短时间内说服他。
第4章 乐高王国
模块化和组件化是软件人员的梦想，谁都想把几个模块插到一起就可以完美的运行并完成任务，但现实却相当残酷，可以运行的模块通常不能与自己想写的程序配合工作，好的源代码由于商业利益也不太容易找到，程序员只能自己另起炉灶，搭建自己的模块，但结果还是一样，做出来的东西难以让他人共享，这个现象周而复始，不断地在多个程序员身上上演。
最近有一个叫组件管理方面的项目，听起来让人毫无信心，连运行在什么平台上、给什么用户使用都不清晰，这样的组件管理有什么用？还不如就叫做文档管理算了。
书中提到一个叫考克斯的人，他创办了一家叫做Stepstone的公司，致力于向C语言系统搭造者提供插入式芯片级软件组件，最后的结论是：坏消息是这次试验显示，即便采用最新的技术，要想设计和制造既有用又真能复用的组件、为组件写文档以便于客户理解、移植组件到潮水般不断涌现的新硬件平台上、确保最新的改进或发布版本不与现存接口冲突、将组件销售到类似威廉姆斯堡枪械行业那种鼓励从头做起的价值体系，都是极其困难的。
可复用软件之梦有一个悖论：几乎总能找到一段满足大部分需要的代码。但这些拿来的代码所不能做到的部分，恰恰是项目与众不同的创新之处----也是创建这个项目的出发点。
第5章 管束奇客和狗
质量三角，既好、又快、还便宜，同时满足的事情不太可能发生。
从程序员转做经理常被说成是做了“前脑叶白质切除手术”，这个术语还是从刚从《How We Decide》这本书看到过，这种手术会让患者更新丧失感情、不知爱恨悲喜。国外技术人员不愿承担项目经理这种管理岗位，而在国内正好相反，许多时候还是不会编程的人来管理。
用代码行数做判断标准只会鼓励程序员写臃肿、蹩脚的代码。
闲逛式管理MBWA(Management by wandering around)好像不能移植到软件领域中。
关于奇客的2种定义：
以（计算机）程序缺陷为食----不善社交、身有恶臭、面色苍白的偏执狂，具有奶酪刨丝器一般的人格特点。
专注于己事的人；追求技术（特别是专业技术）和梦想、不融入主流社会的人。
群件Groupware：即时通信、聊天室、缺陷跟踪、源借故传统的邮件列表等工具，个人感觉要慎用这些工具，否则你的工作时间会被这些工具吃得一干二净。
Wiki在chandler项目中也建立了起来，感觉这个chandler项目用到的工具太多，如果程序员不能合理地安排自己的时间，估计会被这些工具所淹没。
对于程序员来说，确实有一种制造工具的冲动。磨刀不误砍柴功本身没错，但程序员在磨刀的过程中会想弄到一块最好的石头，并花了大把的时间去把刀磨得吹毛断发，却忘了还要砍柴。
个人感受：
1》通过阅读前五章，我发现了一个道理，向已经延误的项目中投入人力，只会更加浪费资源，就像我们团队开发项目中某个阶段延误了之后，总想着人多力量大，但是我们发现由于人员有限，向这个项目中投入人员，不但没有解决延误的问题，还会产生新的问题，是其他项目延误。
2》书中的一个很好的比喻是，“十月怀胎，无论多少妇女参加都一样”。
3》在今后的团队开发中，我们要衡量好团队项目的开发人员分配，不可以本着“人多力量大”的态度，一味的向已经延误的项目中投入人员，这样很有可能会使项目停滞不前。