我花了大概四个晚上（也包括白天的一些时间，不过白天的时间还是较少）阅读完这本书，说“完”，不算很确切，因为，有些地方是跳读的，有些读过的地方也并读不懂，毕竟我不是程序员，而且也不要求自己一定要读懂，我的目的在于了解chandler开发的历史，探究项目失败的原因。
说到缘起，还是和近来研究的GTD有关。在试用了多种GTD软件之后，我开玩笑地说，这些GTD软件都不好用，还不如自己设计一种。在对某位同事提及时，同事立即推荐了一个软件，chandler，一本书，《梦断代码》。
我很喜欢这种方式。他支持你的想法，但是，又能够给出适宜的建议，提醒你有可能面临的问题。相比完全不考虑风险的支持，以及毫不考虑成功可能性的大泼冷水，这是中庸的路线。
我从来不会自信到认为同样的事情，别人做会失败，唯有我可以成功；也不会因为同样的事情别人失败了，我就认为自己一定不会成功。GTD软件，是一个玩笑，可能做，也可能不做，尤其不会是放在今年做，因为今年我很清醒地知道除了我的工作要倾注大量心血之外，还有个人知识管理的研究要进行，这都是需要专注的事情，要得，就必须舍。
但是，这不妨碍我阅读这本书，事实上，我对这本书充满了期待，因为，诚如这本书的封面上所写的，“两打程序员，3年时间，4732个bug，只为打造超卓软件”，这样好的条件，为什么还会失败？从梦想到失败的路线，未必仅适用于一事，我相信，对于我所正在探究的个人知识管理，同样有借鉴作用。
当然，在读完这本书之后，我还是认为，我读这本书时间晚了，它最适合我的时间，应是在2004年至2005年间，当时我还在从事产品经理工作，正属于软件开发的一部分，我懊丧地发现，在离开产品规划4年之后，这个领域对我已经颇为陌生，可能对我来说，最具体的技能仅剩下项目管理——让我不要为我失去的而悲伤，反之，为我还拥有的而庆幸吧，幸而还有项目管理——也是因为有这点底子，我的确为chandler的开发过程感到惊异，有着美好的愿景，却没有良好的项目组织结构，也没有项目进度管理，过于宏伟的目标，不断转换的方向，不断推迟的进度，这些都是开发的大忌，却在一群优秀的人们之中上演达数年之久。
目前，很多开发人员，往往都在抱怨项目时间紧张，压力巨大，如果他们看过《梦断代码》，可能就会明白，没有时间压力，未必是能够制造出完美软件的必要条件，相反，那可能是一种扼杀，正是基于这个原因，不少程序员离开了chandler项目组，因为他们无法容忍长期制作不出产品。改变世界的梦想，终究需要一个实际的载体，否则，就只是自欺欺人。
这本书我先看到这里，我想目前我想拿到的答案已经拿到，暂时不准备重读，但这是一本好书，也许将来还会用到。
记录一些零碎的火花：
P51，意大利激进分子安东尼奥·葛兰西曾有名言云：要想改变世界，你得“理智上悲观，意志上乐观。”
P240，关于37 Signals的开发经验介绍，和chandler相比可以说是两个极端，但是前者成功了。照他们的做法，“约束是朋友。’约束是打造伟大产品的关键‘，弗瑞德说，’约束产生创意。如果有人说，给你全世界的财富，让你做任何想做的东西，那这东西多半永远发布不了。给我一个月就好！‘”
P254 关于软件工程师、硬件工程师和部门经理的故事，既滑稽也有借鉴意义，尤其是部门经理的那个思维，看后悚然暗惊，感觉和自己目前的状况是蛮象的。如果一味追求战略能力，却无法落实到战术，那么，当遇到危险情况，可能束手无策，或者纸上谈兵。这是需要戒之慎之的事情。
P310，作者提到一种Ecco Pro软件，“你手中的这本书，其全部研究工作的组织、汇整、纲目、交叉引用以及无穷无尽的调整也是用一套基于1993初次发布的Windows程序Ecco Pro来做的”。有机会的话，试用一下这套软件，看是否可用于写书。《名博是怎样练成的》是纯用DOC写成的，应该尝试一种不同的方法，现在是在用OneNote来组织资料，如果有更好的方式，当然是要用用试试。
P314，卡普尔说，“如果感到自己太过绝望，应该置之不理，避免采取行动——因为这种感觉往往是暂时的，多数只是见景生情。我反而会出去一段时间，一个小时、几个钟头、一天或两天。取决于何时能够重新振作精神”。这是一种情绪管理的办法，可以借鉴。
韩磊的翻译非常好。
附记：
我在0：26分开始写这篇文字，0：52分结束正文。我知道我突破了我的规律生活（23：00左右睡觉），但是，计划应该有灵活性，不能一味固执，在初读完此书之后，那种略含伤感的情绪，我希望能够记录下来，否则，到了次日，这种情绪会消散，写的文字的调子，会有不同。文字，很多时候就象钉子一样，能够把流动不止的潮水凝固成一幅画像，在回顾的时候，看到文字，也就看到心情。