Tanenbaum的计算机教学十大准则第十条就是“勿忘过去”， 中国古语亦云，读史使人明鉴，《梦断代码》就是一本软件开发史。为什么好软件难做？整本书围绕这个问题，以开源日历软件Chandler的开发历程为主线，将软件技术、软件工程和geek们为将项目从焦油坑中拯救出来尝试的各种方法交织在一起，用包含感情的笔墨描写了艰辛曲折的真实软件开发故事，比小说更动人心弦。做软件不是造桥，不管前人总结了多少技术经验，为之花费了多少青春，多少心血，仍然有可能面临失败。没有什么比这更让软件人心碎了。多少人想构建理想的乌托邦之国，一个个头破血流，可贵的是仍有人前仆后继，努力做到最好。这里的动力可能来自程序员的“洁癖”，追求完美，想事事做到圆满，想把代码写到让人信赖甚至依赖。为此，程序员几乎想尽了办法。有人总结方法，而Joel spolsky说，“方法论的真正目的，是卖书，而不是真正解决问题” 。有人提出不断重构，而现实是“重构常被比之于园艺修剪：它永远做不完” 。有人制作计划并跟踪进度，“多数开发者都乐意告诉经理自己的进度，问题是，就目前的软件实践而言，开发者们对于自己的进度也不比经理知道得多。”有人企图构造“可复用的代码段”，建立一个理想之国，在那里，“程序员只要写一次组件，就能到处复用。在打造大型新项目时，程序员可以站在也许更高的巨人的肩上” 。可是这种尝试屡屡失败。“无关乎志向，亦无关乎技能，只因为难题源自软件的多样性，根深蒂固且难以解决。” 乔布斯的“改变世界”振奋人心，可是如果是一个空中楼阁式的目标，即使不缺钱，不缺时间，不缺技术，也很有可能变成一个当代巴别塔，“梦幻一场”。可怕的是，Chandler的失败原因似乎隐藏在许多的软件开发之中。模糊并不断变化的需求，在很多决定上摇摆不定，花大量时间讨论不重要的问题，在写真正产品代码时发现需要另一个小软件，于是重新去发明一个轮子，项目远远没有开始收敛的迹象，而bug又蜂拥而至，一片混乱。 Chandler不是一个孤独的，看网上有一段评论调侃为什么Chandler是一个成功的项目：
- 它只跳票了5年。（《永远的毁灭公爵》跳票了13年）
- 它只消耗了数百万美元。（《永远的毁灭公爵》消耗了两千万美元）
- 它毕竟推出了1.0版本，虽然反响很差。（《永远的毁灭公爵》只推出了一点图片和视频，还有无休止的谣言）
- 它是开源项目，未来也许会有人在它这里找寻灵感，只是也许。（《永远的毁灭公爵》连这个也许也没有）
- chandler更换关键架构的次数没有《永远的毁灭公爵》多。
理智上悲观，意志上乐观，我们还是愿意相信可以改变这种局面。代码很难重用，但是思想是可以的，书中提到的实用最小主义，如果Chandler一开始遵循了这个原则，结局应该不会如此凄美。原则基于以下三条：
1）尽量少的人。这意味着沟通成本的降低，意味着更容易较为完整的相互理解彼此的思路，意味着软件团队开发中涉及最复杂的因素“人”的问题在理论上的减少。 2）尽量少的时间。这意味着人出于谨慎原则会更青睐于选择自己最熟悉的解决方案，这里的解决方案指的是平台、框架、思路等等。 3）尽量少的功能。这意味着只能选择最有把握实现且最为贴近根本需求的功能。
本书也深入分析了方法论，相比CMM或敏捷，Joel spolsky有一个快速自检列表，就是有名的JOEL测试，基于以下12个问题： 1.使用源代码控制吗？（版本控制） 2.每步都做构建吗？（从源码到目标文件的构建使用一个脚本来自动完成）
- 做每日构建吗？
- 你们有缺陷数据库吗？
- 在编写新代码前修复缺陷吗？
- 有与当前工作吻和的进度安排吗？(进度表不及时更新，或者总是延迟于里程碑，等于没有进度表) 7.有规格说明书吗？（如果实际开发根本不照规格书去做，或者规格书只是走形式的含糊描述，等于没有规格书） 8.程序员拥有安静的工作环境吗？ 9.你用到了你资金能力内可买到的最好工具吗？ 10.有测试人员吗？ 11.新聘人员在试用期内写代码吗？ 12.进行走廊可用性测试吗？（在走廊里随便揪一个人，让他试用你写的代码）
书中还提到了对开发人员的管理。对许多管理者来说，这一群喜欢钻细节到每一个比特的程序员是很难沟通的，他们喜欢探索、观察并发现事情本质。同时，他们又是乐观的，虽然软件开发存在着诸多通病，可是他们坚信“这次会不同”。“软件就是麻烦一堆，而且我们不能够也不愿意把电脑一关走为上计。给我们带来挫败和束缚的软件，也用更多功能、更快更好的工作与生活方式来引诱我们。无路可回，我们对软件的需要，远甚于对它的仇恨”。即使代码注定要被遗弃，但大家仍醉心于创造美丽代码。