本书所谈到的内容，无外乎在证明软件开发确实是一件件颇为痛苦的事情——以Chandler为主线，讲述了这款PIM工具从筹备到诞生的过程，其间穿插了各种小故事，反映出来的问题，均是现实工作中真实存在的，甚至多数是现在还能见到的（意味着什么，我就不明说了）。
之前用过Chandler，感觉功能不尽人意，得知它也纯属看了它的新闻，一时好奇才去安装使用。如同之前所了解到的一样，Chandler一直处于很纠结的状态，所以无法落笔进行设计。和文中所提到的内容一样，团队将Chandler想象得过于重要，收集了过多的需求——过度设计了，导致在实现的过程困难重重。
另外，除了Chandler这条主线外，书中还穿插了很多小的故事——基本上现在各种熟知的语言、软件，如Python、Java、Wiki等都在书中有提到。
把软件和工程关联在一起，本意是没错的，可是你能想象的到，一幢设计好的大楼在建筑过程中又要改来改去，甚至可能推翻之前的一些——这种楼你敢住吗？没错，国内很多软件相信都是这么来的~
文中提到，要解决当务之急，轮子到处都有，关键是要合理利用。反观国内很多企业，从不考虑利用的问题，而是不断地发明轮子（至于到底是不是自己发明的就不得而知了），还高举着“自主知识产权”的牌子，真实令人无语。
反思目前的公司，不会做集成，工具其实都还可用。公司喜欢重复发明轮子，不解决当务之急，而是取远水（投入大量人力物力，如同Chandler一样，还木有影呢——据说要实际投入使用得明年或者更晚……）。想想，公司还真是有钱有时间啊……重新发明轮子，那总得有突破吧？关键问题是没有新的东西（代码重新敲一遍就成自己的了？）。
感慨的东西不少，以后再一点一点结合实际反思。
不过，Chandler现在怎么样了？最灵活的数据结构是XML么？
下面是一些摘录的内容：
只有在任务能够分派给许多互相之间无需沟通的工作者时，任何月才可以互换。
注重序列约束，避免先决条件处理出现问题。
从小项目开始，而且永远不要期望它变大。如果这么想，就会做过度设计，把它想象得过于重要。更坏的情况是，你可能会被自己想象中的艰难工作所吓倒。所以要从小处起步，着力考虑细节。别去想大途径和好设计。如果项目没解决某些眼前的需求，多半就是过度设计了。
大型软件生产已经成为一种管理上的恐慌事务。它常被看作是无利可图的沼泽，既费钱又没完没了。
抽空了解的内容：
A、祖尔测试（Joel Test）——不会叫人头疼的CMM：
1. 你们使用源代码控制吗？
2. 你们每步都做构建吗？
3. 你们做每日构建吗？
4. 你们有缺陷数据库吗？
5. 你们会在写新代码之前修复缺陷吗？
6. 你们有与当前工作吻合的进度安排吗？
7. 你们有规约吗？
8. 程序员工作环境安静吗？
9. 你们采用了市面上最好的工具吗？
10. 你们有测试人员吗？
11. 你们会要求应聘者在面试时写代码吗？
12. 你们做走廊可用性测试吗？
B、BaseCamp，RoR，37Singal的设计哲学
C、SketchPad的输入时间、日期的方式十分高效。
D、Big Design Up Front